И. Аверчев. Программное обеспечение для строительных организаций

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

Все программные продукты можно разбить на несколько групп – как по назначению, так и по цене. По назначению в учетном процессе программы можно разделить на:

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

Ценовой разброс программ каждой группы весьма велик: от нескольких долларов до десятков сотен тысяч долларов. Рассмотрим их.

Универсальные электронные табличные процессоры

Самыми простыми в эксплуатации, самыми дешевыми и самыми распространенными программными продуктами, используемыми при подготовке отчетности, являются табличные процессоры. К ним относятся Excel (широко известный, благодаря тотальному применению в России продуктов Microsoft), Lotus или Quattro Pro.

Безусловное достоинство этих программ — простота в использовании.

Недостаток — невысокая надежность результатов.

Как показало специальное исследование, проведенное крупнейшей аудиторской фирмой в 2002 году, примерно 80% всех ошибок, найденных в финансовой отчетности компаний, связано с использованием в процессе подготовки отчетности электронных таблиц. Действительно, достаточно внести изменения в одну из взаимосвязанных таблиц, введя новые строки или столбцы, как могут быть нарушены все взаимосвязи между таблицами и, как следствие, появиться ошибки в окончательных результатах.

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

Достаточно плохо защищены таблицы от:

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

Одним из решений этой проблемы является обязательное использование в таблицах контрольных точек (ячеек, которые содержат некоторые промежуточные вычисления). Например, любой бухгалтер знает уравнение: Активы = Обязательства + Капитал. Следовательно, при подготовке отчетности, для того чтобы проверить правильность составления отчета, достаточно выделить ячейку, где будут суммироваться все активы, и из этой суммы будут вычитаться обязательства и капитал. Эта ячейка для верно составленного балансового отчета всегда равна нулю, поскольку активы-обязательства-капитал=0. Ну, а ненулевая сумма будет являться признаком ошибки.

Электронные базы данных

Гораздо более надежными продуктами, используемыми при подготовке отчетности, являются электронные базы данных типа MS Access (рис. 1).

Рис. 1

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

Специализированные бухгалтерские программы

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

Такие программы выпускают как небольшие отечественные компании, так и трансконтинентальные холдинги в достаточно широком стоимостном диапазоне (от сотен долларов до нескольких миллионов).

Среди российских производителей программного обеспечения, позволяющего формировать отчетность по нескольким стандартам, можно отметить:

• 1С-RARUS
• 1С-PB
• Инотек

Из западных программ, представленных на российском рынке, стоит отметить:

• Scala
• Sun Systems
• Microsoft Navision
• Microsoft Axapta
• SAP R/3
• PeopleSoft
• Oracle Financials

При выборе программы надо помнить о том, что:

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

Помимо этого, важнейшим для строительного бизнеса моментом в выборе специализированных программ является наличие высокоэффективного блока пообъектного учета затрат. Для этих целей в учетных системах разрабатываются взаимосвязанные модули Job Estimating («Сметы») и Job Cost («Затраты»). В первом модуле вводятся все сметы по всем проектам, которые выполняются в данный момент. Во втором проводится пообъектный учет затрат (рис. 2).

Рис. 2

Наиболее удачное в этом смысле отраслевое программное решение МАГ-Строитель, разработанное на платформе Microsoft Axapta, уже упоминалось нами в одной из предыдущих статей.

Большинство программ, которые предлагает рынок в том или ином виде, дает возможность пообъектного учета. Приведем скриншот самой популярной программы 1С (рис. 3).

Рис. 3

Системы планирования и бюджетирования

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

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

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

К числу западных таких программ относятся:

• Geac (Comshare MPC)
• Hyperion
• OFA
• SAP SEM
• и ряд других

Среди российских можно назвать BPlan.

Типичная бюджетная модель девелоперской компании состоит из следующих бюджетов:

• Бюджет продаж
• Бюджет затрат на строительные работы
• Бюджет управленческих расходов
• Бюджет коммерческих расходов
• Бюджет развития
• Бюджет расчетов с банками
• Бюджет расчетов с инвесторами
• Бюджет Движения Денежных Средств (БДДС)

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

Рис. 4

Для бюджета продаж, с которого начинается процесс бюджетирования, необходимо формирование сложной многомерной структуры в том виде, который наиболее удобен в работе.

Скриншот бюджета продаж и данные для анализа «План-Факт» по статье «Выручка» за январь в разрезе объектов и типов квартир показан на рис. 5.

Рис. 5

После бюджета продаж, как правило, разрабатывается бюджет затрат на строительные работы, один из возможных вариантов которого приведен на рис. 6. Все статьи затрат (выполняемые работы) группируются в четыре основные главы: «Подготовка территории строительства», «Основные объекты строительства», «Объекты энергетического хозяйства» и «Непредвиденные затраты». Справочник статей затрат должен быть разработан таким образом, чтобы имелась возможность использовать его без изменений для всех объектов. На рис. 6 приведен пример бюджета затрат на строительные работы в режиме план-фактного анализа по «Объекту 1» по итогам февраля.

Рис. 6

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

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

Рис. 7

Бюджет расчетов с инвесторами содержит плановые и фактические поступления внешних инвестиций с аналитикой по конкретным инвесторам (рис. 8).

Рис. 8

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

Рис. 9

Еще раз подчеркнем основные задачи, которые решает бюджетирование денежных потоков, наиболее часто используемое в компаниях сферы недвижимости:

• Управление платежеспособностью и ликвидностью компании
• Анализ бюджета продаж в разрезе объектов, версий, клиентов, каналов сбыта, типов квартир и других
• Получение наглядной картины структуры затрат на строительные работы
• Управление взаиморасчетами с кредиторами и инвесторами

Прочие программы

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

Логистические системы позволяют оптимизировать товарные потоки.

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

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

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

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

Например, при помощи поисковых машин Интернета можно легко найти информацию по нормативам в строительстве. СНиПы и СанПиНы можно найти по адресу: http://www.vashdom.ru/norms.htm или http://www.vashdom.ru/sanpin.htm.

Пробная версия системы бюджетирования BPlan с конфигурацией для строительных фирм находится по адресу: http://www.bplan.ru/what/building.htm. 

Е. Донцова. Создание отраслевых решений на базе ERP

Туфли, которые подходят одному человеку, жмут
другому; нет рецепта, как жить, который подходит
для всех случаев.
Карл Густав Юнг

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

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

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

Скорее всего, после такого вступления у многих читателей, хоть раз интересовавшихся вопросом внедрения ERP-систем на предприятиях своей отрасли, сразу же напрашивается разумный вопрос: «Почему же тогда при всех вышеперечисленных плюсах ERP-систем количество удачно завершенных проектов внедрений на предприятиях строительного комплекса не так велико, если не сказать исчисляется единицами?»

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

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

В последнее время на рынке ERP-систем все чаще появляются новости от производителей программных продуктов или от консалтинговых компаний, занимающихся внедрением, о создании отраслевых решений.

В наши дни отраслевые решения — объективная реальность, без них успешно не работает практически ни одна серьезная консалтинговая компания.

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

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

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

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

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

Наверное, для того чтобы разобраться в проблемах, которых можно избежать при внедрении готового отраслевого решения, нужно обратиться к проблемам, возникающим на пути его возникновения. Как говорится, успех – это 99 % неудач. Обратимся к истории. Для «разбора полетов» вниманию читателя  будет представлен опыт внедрений системы Microsoft Business Solution-Axapta в строительных компаниях, на основе которых созданы два отраслевых решения, на данный момент официально зарегистрированных компанией Microsoft Business Solution: «МАГ-Строитель» и «МАГ-Риэлтор».

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

Как показывает опыт, строители довольно неохотно идут на изменение организации процессов и ежедневных операций, требуя гарантий нормального их функционирования после внесения изменений.

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

Отраслевое решение «МАГ-Строитель» предназначено для реализации управления затратами по строительным проектам, оперативного контроля исполнения смет, что, как правило, является «большой головной болью» в строительных организациях. «МАГ-Риэлтор» представляет собой автоматизацию деятельности риэлторов, т.е. управление продажами объектов недвижимости. Создание этих решений происходило в процессе внедрения системы MBS-Axapta в строительном холдинге на основе поставленных задач по учету каждодневных операций для получения точной и прозрачной сводной отчетности.

Решение по контролю исполнения бюджетов строительных проектов создавалось с целью автоматизировать следующие процессы:

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

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

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

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

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

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

Функциональность повседневных операций риэлторов по продаже квартир интегрирована с финансовым блоком по учету дохода от продажи квартир и дебиторской задолженности.

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

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

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

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

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

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

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

 «Именно то, как вы собираете, организуете и
используете информацию, определяет,
победите вы или проиграете».
Билл Гейтс

В. Ларионова. Программные продукты для промышленно-строительных холдингов

Программные продукты для промышленно-строительных холдингов

Валентина Ларионова, консультант МАГ КОНСАЛТИНГ

Статья опубликована в газете "Финансовая газета", №38, 2004 

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

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

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

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

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

Итак, рассмотрим необходимый набор программных продуктов для автоматизации системы в строительном холдинге полного цикла, предоставляющем весь спектр услуг: от создания идеи проекта и его бизнес-плана (включая затем финансирование и непосредственно сам процесс строительства) до реализации построенных объектов и управления недвижимостью:

• Учетная программа (для автоматизации бухгалтерского и налогового учета) поддерживающая  отраслевую специфику деятельности
• Автоматизированная система плановых расчетов (для расчета строительных смет)
• Автоматизированные системы управления строительством (для управления проектами строительства  на всех стадиях)
• Система автоматизации проектных работ (для архитектурного и инженерного проектирования объектов строительства)
• Геоинформационная система (для решения территориально-распределенных задач)
• Корпоративная информационная система для управления ресурсами строительного предприятия или группы компаний (ERP-система, поддерживающая специфику отрасли).

При выборе программ для бухгалтерского и налогового учета лучше ориентироваться на те, которые учитывают отраслевую специфику. Такие широко известные разработки компании 1С, как  «1С: Заказчик строительства» и «1С: Подрядчик строительства», позволяют помимо общего ведения учета и составления отчетности планировать и учитывать затраты в разрезе объектов строительства, в рамках утвержденных смет,  вести учет выполнения строительно-монтажных работ в разрезе строек, объектов строительства с оформлением документов по отраслевым формам (КС-2, КС-3 и других). В них также предусмотрены возможности  вести отраслевой учет производственных запасов, работы автотранспорта и внутрихозяйственных расчетов. 

Следует помнить, что обязательным условием для любой учетной программы является совместимость с программой расчета строительных смет. К примеру, конфигурации 1С могут работать с продуктами «Смета 2000», «WinСмета», «Гектор», ПК «Сметная энциклопедия» и другими.

К сметным программам предъявляются следующие требования: широкий выбор методик расчета смет (ресурсный, базисно-индексный, базисно-компенсационный, смешанный), наличие всевозможных нормативных баз данных (1984, 1991, МТСН 81-98, ГЭСН, ТЕР и других), обеспечение одновременной работы в сети нескольких пользователей.
Программы «Гектор: Сметчик-строитель» (разработчик ООО НТЦ «Гектор»), ПК «Ресурсная смета», «Смета 2000» (Разработчик ООО «Фирма СтройСофт»), имеющие сертификацию Госстроя России, соответствуют указанным требованиям. Кроме того, например, ПК «Ресурсная смета» содержит также дополнительную информацию (ЭСН, производственные нормы списания, тексты действующих методических документов). 

Сметные программы такого уровня позволяют производить расчет локальных, объектных, сводных смет, актов выполненных работ (КС-2), накопительных ведомостей (КС-6), ведомостей потребности и списания ресурсов (М-29), справок по форме КС-3, ведомостей фактического удорожания материалов, учет выполнения  по подрядчикам, мониторинг цен, индексацию цен ресурсов и многое другое.

Дополнительным плюсом сметной программе является ее способность к интеграции с системами календарного планирования и управления проектами. В частности, «Гектор: Сметчик-строитель» позволяет передавать информацию  в системы Spider и Primavera.

Автоматизированная система управления строительством, например, универсальная система Spider Project (разработчик «Технологии управления СПАЙДЕР») позволяет  получать полную информацию о реализуемых проектах, анализировать проект с разных сторон, планировать расписание выполнения работ и оптимальное использование ресурсов. Среди ее пользователей СК Баркли, Строймонтаж, Мой Дом (Владивосток), Мосводоканал и др.

Некоторые системы имеют специализированные решения для строительной отрасли. Например, Primavera P3e/c for Construction (разработчик Primavera Systems, Inc), рассчитанное на управляющие строительные компании, крупных подрядчиков, инжиниринговые компании, проектные институты, позволяет составлять все стандартные для строительной отрасли отчеты и графики; контролировать проекты; управлять затратами, ресурсами/запасами; анализировать отчетность. Технические возможности дают возможность каждому участнику проекта получать актуальную информацию в любое время и в любом месте и оперативно реагировать на нее.

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

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

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

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

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

Некоторые ГИС, например Autodesk MapGuide (разработчик фирма Autodesk), представляют собой комплекс программных модулей, предназначенный для создания и развития технологий предоставления ГИС-функций и ГИС-данных в сетях Internet/Intranet. Использование подобной системы позволит организации получить максимальную отдачу от вложений в информацию, технологии и персонал.

Autodesk MapGuide читает данные CAD систем и поддерживает связь с различными базами данных (Oracle, Sysbase, Microsoft Access, Atlas и др.).

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

Скажем, система PeopleSoft EnterpriseOne Real Estate (разработчик американская компания PeopleSoft) предлагает мощный инструмент для риэлтерских компаний, работающий на основе единой базы данных централизованной среды, информация в которой может быть использована для консолидации и доступна в любой момент времени.
Система помогает повысить производительность и точность работы проектного персонала посредством улучшения коммуникаций, минимизировать прямую проектную стоимость, начиная с этапа прогнозирования в режиме реального времени, получить максимальную производительность в самом процессе строительства и использования техники с помощью точной оценки объема работ, повысить окупаемость техники за счет более качественного использования и снижения стоимости технического обслуживания, минимизировать накладные расходы за счет более эффективной интеграции.

Среди отечественных разработок в области ERP-систем можно отметить систему «Галактика - Модуль Управления Капитальным Строительством» (разработчик корпорация «Галактика»), также представляющую собой единую интегрированную систему, автоматизирующую работу отделов аппарата управления и подразделений, задействованных в планировании и учете выполнения капитального строительства. С ее помощью решаются следующие задачи строительной компании: определение потребности в строительстве объектов, составление планов строительства и финансирования, учет плановых и фактических расходов по строительству, ведение договоров с подрядчиками и заказчиками, получение отчетности о ходе строительства и освоении капитальных вложений. Решение предназначено для верхнего, управленческого уровня строительных организаций и не содержит сметных или архитектурных расчетов по отдельным объектам. Для данных работ предусмотрена возможность интеграции со сметными программами и системами автоматизации проектных работ (САПР).

Всерьез же говорить о комплексной автоматизации многопрофильного промышленно-строительного холдинга позволяет  «Интегрированная система для строительства и недвижимости» на базе ERP-системы «Microsoft Business Solutions – Axapta». Разработанная изначально в виде двух дополнительных отраслевых модулей к «MBS-Axapta» (так называемых Add-on решений) «МАГ-Риэлтер» и «МАГ-Строитель», эта система представляет сегодня собой продуктивную основу для решения проблемы объединения всех программных продуктов строительного холдинга полного цикла в единое информационное поле.

Среди уникальных особенностей данного программного комплекса можно отметить реализованную в нем возможность жесткого контроля бюджета строительного проекта на всех этапах процесса бюджетирования: от разработки, согласования и утверждения сметы по тому или иному договору строительного подряда (или объекту в целом), через стадии недельных/месячных или произвольным образом распределяемых во времени заявок на выделение средств, до их подтверждения финансовой службой и оплаты. Система фактически исключает какие-либо, даже малейшие, отклонения от принятого на предприятии порядка и объемов финансирования строительства.
В ней также реализованы оригинальные методики управления продажами квартир в строящихся домах и на вторичном рынке жилья, расчетов с клиентами (с учетом специфики различных форм финансирования девелопмента недвижимости) и многое другое. Интегрируемая с хорошо известным строителям программным продуктом Microsoft Project с помощью специального шлюза, система решает практически все задачи учета и управления крупномасштабным строительным производством.  Чтобы не перечислять здесь заново уже рассмотренные нами и реализованные в других, разнородных программных продуктах функции, обеспечиваемые и данной системой, мы выделили их в тексте нашей статьи курсивом.

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

Объединив же путем создания общих интерфейсов ERP-систему с любыми, пусть даже самыми современными специализированными программными комплексами от САПР до ГИС, холдинг или группа компаний начинает работать как единый организм, не рассыпающийся то и дело на отдельные строительные участки, функциональные департаменты, проектные бюро или архитектурные мастерские. 

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

*   *   *

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

АСПР – автоматизированные системы плановых расчетов (сметные программы)
АСУС – автоматизированные системы управления строительством (проектное управление)
САПР – системы автоматизации проектных работ (инженерно-строительное проектирование)
ГИС – гео-информационные системы
ERP – системы планирования ресурсов предприятия

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

Д. Ерофеев, М. Перепелкина "Корпоративные сети: формат на вырост"

Корпоративные сети: формат на вырост

Дмитрий Ерофеев, Марина Перепелкина

Статья опубликована в журнале "Свой бизнес", № 04 (21), апрель 2004 г.

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

Спонтанные решения: потери гарантированы

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

- Наличие четко сформулированной IT-стратегии может сократить затраты на информационные технологии как минимум в два раза, - считает партнер компании "МАГ КОНСАЛТИНГ" Георгий Ушаков. - Одна из ее главных задач - заранее планировать все изменения. Ведь непредвиденные ситуации влекут за собой непредвиденные расходы.

Важность IT-стратегии наглядно демонстрируют примеры компаний, у которых такой план действий отсутствует.

- Одна стремительно развивающаяся сеть продуктовых магазинов регулярно приобретает и осваивает новые торговые площади, - рассказывает Георгий Ушаков. - В свое время руководство компании не посвящало сотрудников IТ-подразделения в свои планы по покупке новых точек. В итоге однажды, когда был приобретен новый магазин и понадобилось включить его в единую информационную сеть, случился аврал. IТ-менеджеры в срочном порядке закупили кассовые аппараты той модели, которая была принята в компании, и установили их буквально за одну ночь: день простоя точки мог обойтись в десятки тысяч долларов. А впоследствии оказалось, что половину аппаратуры можно было не покупать и не платить подрядчикам лишние деньги за скорость установки. Всех этих потерь можно было бы избежать, если бы расширение бизнеса было согласовано с IT-стратегией компании.

- Самая распространенная беда, к которой приводит спонтанное принятие решений в сфере IT, - нестыковка в работе двух подразделений: бухгалтерии и службы финансов, - считает Николай Красилов, президент корпорации "Галактика". - На многих предприятиях они используют программное обеспечение разного формата, и их отчетные данные невозможно объединить, чтобы сделать полноценный анализ. Почему это происходит? Потому что каждое подразделение самостоятельно решало, что необходимо именно ему.

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

Снижение затрат или наращивание прибыли?

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

- Часто чрезмерные траты на IT, излишняя автоматизация только вредят. Особенно если информационные технологии выполняют в фирме исключительно сервисные задачи, - рассказывает управляющий партнер компании "МАГ КОНСАЛТИНГ" Андрей Гершун. - Например, известно, что ручное выписывание счета занимает две минуты, компьютерное - семь. Для многих компаний - например, мелких оптовиков - важным конкурентным преимуществом является в первую очередь скорость обслуживания клиентов. Поэтому многие из них только проигрывают, полностью автоматизируя все свои бизнес-операции.

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

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

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

Какую задачу сделать приоритетной: минимизацию за счет IT своих затрат или оптимизацию своих конкурентных преимуществ? Это зависит от стратегических целей компании.

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

Прописано на бумаге...

IT-стратегия - это документ размером не более трех-четырех страниц.

- Мы советуем описывать правила работы по основным направлениям "широкими мазками" и в каждом пункте делать сноски на дополнительные разъясняющие документы. В противном случае на создание и утверждение стратегии могут уйти месяцы, - говорит Георгий Ушаков.

Представления о том, что включает в себя IT-стратегия, у специалистов разнятся в деталях, но в целом совпадают.

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

Несколько другой план предлагает Андрей Гершун:

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

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

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

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

...И опробовано на практике

Как представляют себе суть IТ-стратегии владельцы предприятий, не являющиеся экспертами в области информатики? Председатель совета директоров сети супермаркетов "АБК" Владислав Егоров признает, что его компания имеет четко сформулированную IТ-стратегию, в которой информационные технологии выполняют поддерживающие функции:

- На IT мы тратим около 1% от оборота, - рассказывает Егоров. - Этого хватает на то, чтобы поддерживать в рабочем состоянии парк компьютеров и кассовых аппаратов. Принципиальным требованием ко всем IТ-решениям мы считаем надежность - сбои в работе магазинов не допустимы. Отсюда, к примеру, такой пункт, прописанный в нашей IT-стратегии: программы, которые мы инсталлируем, не должны нуждаться в серьезных индивидуальных настройках и доработках, они должны быть успешно апробированы на нескольких предприятиях схожего профиля. Помимо этого, мы зафиксировали в стратегии, что не боимся автоматизировать различные участки бизнеса по отдельности. Дублирование информации в разных программах мы воспринимаем как усиление надежности работы в целом, хотя большинство специалистов считают это организационным недочетом.

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

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

Не догма, а руководство к действию

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

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

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

- Оперативные планы в рамках нашей стратегии мы меняем в зависимости от темпов роста компании и внешних рыночных обстоятельств, - рассказывает Сергей Рыжков из консалтинговой компании "Прайм Групп". -- Так, после дефолта 1998 года мы пересматривали их каждую неделю в течение трех месяцев. В 2003 году мы пересматривали свои IT-планы уже только раз в месяц, а в 2004 году надеемся делать это не чаще, чем раз в полгода.

Кто за все это ответствен?

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

- По правилам, IT-стратегию должен создавать технический директор компании или как минимум IT-специалист, обладающий бизнес-мышлением, - считает Георгий Ушаков. - Конечно, среди наших айтишников чаще встречаются "инженеры", которым стратегические задачи не под силу. Однако стратеги есть и на рынке IТ-специалистов: кто-то вырастает из "инженеров", кто-то приходит из бизнес-консультантов, кто-то проходит обучение по специализированным программам, например по курсу МВА для технических директоров.

Услуги по разработке IT-стратегии сейчас предлагают многие консалтинговые компании. Однако переложить эту задачу на их плечи не удастся. Абсолютное большинство экспертов и бизнесменов уверены: IT-стратегия должна создаваться внутри компании.

А. Гершун "Сон в новогоднюю ночь: деноминация и бухгалтерские системы"

Сон в новогоднюю ночь: деноминация и бухгалтерские системы

Андрей Гершун

для АКДИ "Экономика и Жизнь"

--------------------------------------------------------------------------------

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

Удаление трех нулей - это очень удобно. Несколько лет назад многие бухгалтерские системы были специально переработаны, чтобы обрабатывать большие суммы в рублях. Например, ранее некоторые пакеты отводили всего по 12-13 знаков на всю сумму, включая десятичную запятую. Кое-кто усмехнется, вспомнив, как ему приходилось оприходовать самолет раздельно, как два крыла, фюзеляж и хвост. Кстати и меньших братьев бухгалтерских систем - калькуляторов уже давно "зашкаливало", не говоря о том, что даже обыкновенные бухгалтерские счеты имеют всего по 7 рядов и рассчитаны на суммы не более чем в 10 миллионов.

Опыт деноминации уже есть у многих российских и западных пакетов, которые проводили внедрения за рубежом. Почти все страны Содружества Независимых Государств ввели в течение последних 5 лет свои собственные валюты. По сути это была та же самая деноминация, только сопровождаемая еще и изменением названия валюты (одна лишь Белоруссия обошлась без того и другого). Одной из последних денежных реформ была на Украине, которая прошла в прошлом году, заменив купоны на гривны по курсу 1:100000. Те компании, кто уже разработал технологию проведения деноминации, сейчас имеют "фору". Некоторые западные бухгалтерские системы имели шанс опробовать свои утилиты для деноминации в Польше, когда злотый был поделен на 10000. Но из-за серьезных изменений, вносимых в системы при адаптации к российскому законодательству, утилиты придется серьезно переработать.

Если поделить одно число на другое (даже такое "круглое" и "хорошее", как 1000), то нам придется столкнуться с округлением. В основу алгоритма округления деноминации было положено знакомое школьное правило: "... если при пересчете цен, тарифов, надбавок, наценок и скидок образуются дробные части копеек, сумма должна быть округлена до целой копейки. Если дробная часть копейки менее полкопейки, то она отбрасывается и сумма снижается до целой копейки, а если эта часть равна полкопейке и больше, то сумма повышается до целой копейки." Но оказывается не все так ясно. К сожалению, инструкции не дают ответа на какой счет отнести возникающую в результате округления разницу. Отсутствие ответа, по утверждению разработчиков многих программ, является сдерживающим фактором при разработке утилит для деноминации. Хотя думается, что с точки зрения налоговой инспекции, ответ был бы универсален: "если получается убыток, то отнести на 81-й счет, а если прибыль то на 80-й, лишь бы налогооблагаемая прибыль не снижалась."

Кстати, многие бухгалтерские системы уже содержат специальные процедуры для коррекции округления возникающего в процессе работы. Самым простым примером является округление статей бухгалтерского баланса и других отчетов до тысяч рублей, когда возникающая разница в 1-2 тысячи рублей обычно добавляется к какой-либо "малозаметной" статье баланса.

Округление может возникнуть не только в балансе. Например, оно также всплывет при деноминации накладных и счетов. Действительно, если у нас есть накладная на 100 единиц товара общей суммой в 123456 рублей (то есть каждая единица товара стоит 1234 рубля 56 копеек при нынешнем масштабе цен), то после деноминации накладной мы получим 123 рубля 45 копеек, а если подсчитаем сумму как 100 единиц товара по 1 рубль 23 копейки, то получим общую сумм накладной в 123 рубля 00 копеек. Конечно же разница в 45 копеек (даже в новых ценах) не настолько значительна, чтобы о ней говорить серьезно, пока у вас 100 единиц товара. Скорее всего вы получите "висящую" задолженность за покупателем на эти самые 56 копеек, которую придется потом списать вручную. А что будет, если у вас есть, например, 100 тысяч этих товаров? это уже выйдет в 560 рублей новыми! Эти 45 копеек могут вывести из строя вывести вашу бухгалтерскую систему, так как некоторые программы проводят автоматическую проверку на равенство суммы документа и всех его строк, и если результат не совпадает, они начинают пугать пользователя "страшными" предупреждающими сообщениями.

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

Естественно, что при выполнении деноминационных пересчетов будет тяжело проводить сравнительный анализ по информации за 1997 и 1998 годы. И если сравнить статьи балансов будет не очень сложно (достаточно будет поделить колонку цифр 1997 года на 1000), то произвести сравнительный анализ по себестоимости товаров будет значительно сложнее. Таким образом для пользователей многих бухгалтерских пакетов будет потеряна возможность проведения анализа, который базируется на информации различных финансовых годов. Не забудьте, что форма №2 о финансовых результатах содержит справочную информацию за соответствующий период прошлого года. Будем надеяться, что разработчики решат проблему соответствующего масштабирования цифр за прошлый год (кстати, возможно, что некоторые пользователи захотят масштабировать 1997 год в своих системах, а некоторые нет).

Алгоритм деноминации достаточно прост: достаточно поделить все суммы в рублях на 1000. При этом необходимо учесть следующие моменты:

• Для того, чтобы провести деноминацию бухгалтерской системы, надо знать где хранятся все суммы, выраженные в рублях. Для многих бухгалтерских систем можно определить колонки с суммовыми данными по так называемым "словарям", в которых описана структура всей базы данных (средняя современная бухгалтерская система содержит от 20 до 500 таблиц, в каждой из которых по 5-10 столбцов может содержать информацию о суммах в рублях). При этом в некоторых столбцах эти суммы могут содержать как суммы в рублях, так и в иностранной валюте, а также аналитическую информацию (например, тонны нефти). Естественно, что их делить не надо.
  
• Производя деление, надо помнить о том, что возникает проблема округления. Это означает, что после деления необходимо тщательно проверить все контрольные суммы (как например, сумма активов и пассивов должна быть равна), и внести необходимые коррекции.
  
• При внедрении бухгалтерской системы в каждой конкретной компании обязательно проявится своя специфика. Хорошим примером, является использование дополнительных полей для хранения вспомогательных сумм. Какая бы универсальная утилита бы не была, все равно найдутся две компании, одна из которых в дополнительном поле "ПОЛЕ1" хранит информацию в рублях, а другая в долларах (это особенно актуально для модулей Заработной платы).
  

Если вы используете только Главную книгу, то вам крупно повезло. В таком случае достаточно ограничиться созданием новой базы данных (компании) с планом счетов, и ввести входящие сальдо 1998 года, поделенные на 1000. Это не очень большая работа, так как на начало года сальдо по счетам прибылей и убытков будет нулевое, и соответственно, объем вводимой информации должен уменьшиться раза в два. Для пользователей западных систем, эта работа может быть упрощена за счет использования модулей трансляции/консолидации.

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

Инструкция гласит, что "все выплаты и расчеты, по денежным обязательствам, оформленным до 31 декабря 1997 г. включительно, осуществляются с 1 января 1998 г. исходя из нового масштаба цен." Это означает, что все счета, выставленные вашей компанией до Нового года, потребуется также деноминировать, и кроме того поделить все текущие задолженности покупателей и задолженности поставщикам. Кстати, не забудьте пересчитать цены на продаваемые товары.

Для того, чтобы осуществить перевод вручную, необходимо закрыть все счета контрагентов на 31 декабря (то есть, как бы оплатить) и завести их заново (то есть, выставить) на 1 января. Хотя, этот метод и трудоемок, но он может оказаться самым простым, если клиентов у компании не много. Этот способ может не сработать, если есть в бухгалтерской системе есть ограничения на выставление произвольных счетов.

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

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

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

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

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

Но самые серьезные изменения, которые потребуются внести в программы, заключаются в требовании с 1 декабря 1997 года (интересно, кто-нибудь выдержал этот срок) до конца 1998 года показывать все цены в двух масштабах параллельно. Это означает, что должны быть переделаны не только все ценники и прайс-листы, но также и счета-фактуры и другие документы. Кстати, интересно отметить, что новая форма счета-фактуры, соответствующей этому указу еще не была опубликована. Думается, что это требование не является критичным, и многие поставщики программ решили тихо спустить это дело на тормозах.

Для пользователей бухгалтерских систем, ведущих дополнительно учет по западным стандартам, а также для зарубежных пользователей из Украины, Белоруссии и других стран, рубль является "иностранной" валютой, и соответственно все суммы в рублях должны быть также уменьшены на 1000 раз, а официальный курс рубля снизится соответственно в 1000 раз.

Если разработчики систем уже не позаботились о наших заграничных коллегах, можно порекомендовать следующий подход: завести новую валюту, которую назвать, например, NRR ("новый российский рубль"), списать все рублевые монетарные активы и пассивы в корреспонденции с каким-либо счетом, затем ввести заново сальдо по тем же самым счетам, но уже в новых рублях. Этот подход не пройдет, если существуют неоплаченные счета, оцениваемые в рублях. В этом случае можно как бы погасить (оплатить, сторнировать, и т.д.) эти счета в старых рублях и выставить новые счета в новой валюте. К сожалению, не все системы позволяют менять валюту расчетов заказчика или поставщика, и тогда придется завести их заново. Если же просто изменить курс рубля на 1 января, то это не приведет нас к желаемому результату, так как фактическая сумма не изменится, а только переоценится их стоимость.

Для некоторых мне хотелось бы напомнить, что провести деноминацию придется не только для "белого", но и для "черного" учета. И если основной валютой этой специфичной для России разновидности финансового учета был выбран доллар, не забудьте, что с 1-го января курс рубля к доллару изменится в 1000 раз.

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

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

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

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

Наличие блоков трансляции/консолидации значительно облегчает перевод информации в Главных книгах западных программ. Для этого достаточно создать новую компанию, и оттранслировать закрывающий за 1997 год по курсу 1 к 1000 (если используется блок трансляции) или умножить все на коэффициент владения 0.01% (если используется блок консолидации).

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

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

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

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

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

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

О разработках своих собственных версий утилит деноминации объявили и другие западные программы Exact, Concorde XAL (Columbus IT Partner), Navision (Импакт-Софт) и SAP.

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

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

О. Кафидова "Теория и практика налогового учета основных средств в ERP-системах"

Теория и практика налогового учета основных средств в ERP-системах

Статья опубликована в «Финансовой газете», №36, 2003

Вступление в силу главы 25 Налогового кодекса Российской Федерации (НК РФ) с января 2002 г. стало серьезным испытанием как для российских систем управления предприятием, которые в связи с этим претерпели значительные доработки, так и для западных ERP-решений. Специалистам по внедрению в России западных ERP-систем пришлось оперативно искать новые решения для реализации современного налогового учета на базе существующей бизнес-логики системы. Сегодня поддержка ведения налогового учета является одним из основных требований организаций к системе управления предприятием.

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

Налоговый учет основных средств с точки зрения ERP-систем

Рассмотрим, какие принципиальные отличия возникают между налоговым и бухгалтерским учетом основных средств:

* согласно главе 25 НК РФ амортизируемое имущество нужно распределять по амортизационным группам в соответствии со сроками его полезного использования. Срок полезного использования основных средств определяется налогоплательщиком самостоятельно, но в строгом соответствии с постановлением Правительства Российской Федерации от 1.01.02 г. № 1 «О классификации основных средств, включаемых в амортизационные группы». Всего в главе 25 НК РФ предусмотрено десять амортизационных групп, по каждой из которых установлены верхние и нижние границы срока полезного использования, допустимые методы начисления износа, способы отражения в учете затрат на ремонт;

* в налоговом и бухгалтерском учете для одних и тех же основных средств могут использоваться разные схемы начисления износа. Понятие «схема начисления износа» включает метод начисления износа (линейный, нелинейный), срок начисления износа, норму износа;

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

* для определения сумм ежемесячно начисляемого износа в налоговом учете применяется не норма износа, а срок полезного использования основного средства, выраженный в целых годах;

* для налогового учета необходимо вести регистры основных средств, а также существуют специфические отчетные формы.

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

Реализация обозначенной идеи ведения налогового учета основных средств в ERP-системе заключается в использовании:

* отдельной базы данных в ERP-системе для налогового учета. Данное решение не исключает копирования/переноса информации из базы данных бухгалтерского учета в базу данных налогового учета (например, это актуально для процедуры ввода в эксплуатацию);

* разных схем начисления износа для одного и того же основного средства. Обычно в информационной системе (Navision Axapta, SunSystems) существует возможность отражать операции для каждого основного средства одновременно по нескольким валютам, схемам амортизации и стоимостным показателям.

В Navision Axapta используются модели учета, по которым и выполняется начисление износа. Для налоговой модели учета («TAX») определяются амортизационные группы по российскому законодательству (рис. 1).

Puc. I

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

Рис. 2

Аналитические коды в ERP-системе (в примере обозначена 02-я налоговая группа - значение поля «Tax Group») обеспечивают распределение основных средств на амортизационные группы по сроку полезного использования.

Настройка налогового учета основных средств в СДР-системах

На практике настройка налогового учета основных средств в ERP-системе включает следующие этапы.

Формирование базы данных для ведения налогового учета амортизируемого имущества на основании данных бухгалтерского учета. Этот этап обычно является наиболее трудоемким и подразумевает разбивку существующих основных средств на налоговые группы, определение срока амортизации и первоначальной стоимости объектов по налоговому учету. Здесь важно внимательно отнестись к существующим в российском законодательстве правилам ведения налогового учета:

· не все основные средства в налоговом учете являются таковыми для бухгалтерского учета и наоборот. В п. 1 ст. 257 НК РФ установлено, что под основными средствами в целях налогового учета понимается часть имущества со сроком полезного использования, превышающим 12 месяцев, применяемого в качестве средств труда для производства и реализации товаров (выполнения работ, оказания услуг) или для управления организацией. В состав амортизируемого имущества также не включается имущество, первоначальная стоимость которого составляет до 10 000руб. включительно, стоимость такого имущества включается в состав расходов в полной сумме при вводе в эксплуатацию. Принципы принятия основных средств к бухгалтерскому учету определяются учетной политикой организации;

· особое внимание следует обратить на основные средства, введенные в эксплуатацию до января 2002 г. Эти основные средства принимаются к налоговому учету по остаточной стоимости в бухгалтерском учете на 1 января 2002 г.;

· первоначальная стоимость основных средств в налоговом и бухгалтерском учете может быть различной. По НК РФ первоначальная стоимость амортизируемого основного средства определяется как сумма расходов на его приобретение, сооружение, изготовление и доведение до состояния, в котором оно пригодно для использования, за исключением сумм налогов, учитываемых в составе расходов. Таким образом, нужно учесть следующие варианты:

a) стоимость основного средства в налоговом учете равна стоимости основного средства в бухгалтерском учете;

b) стоимость основного средства в налоговом учете меньше стоимости основного средства в бухгалтерском учете;

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

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

Пример. Основное средство должно быть введено в эксплуатацию в бухгалтерском учете по стоимости 15 000 руб. В налоговом учете первоначальная стоимость основного средства принимается равной 14 000 руб., а в составе расходов отражается часть стоимости основного средства - 1000 руб. (вариант b).

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

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

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

Пример. Пользователь при вводе данных об основном средстве указал вторую налоговую группу и первый период начисления износа - 10/2003. В соответствии с главой 25 Н К РФ вторая группа должна амортизироваться свыше 2 лет до 3 включительно. Информационная система на основе алгоритмов (для второй налоговой группы определен срок начисления износа - 3 года) может автоматически заполнить поле «Последний период начисления износа» рассчитанным значением 09/2006 (10/2003 + 3 года).

Настройка отчетных форм.

Пример. Контролирующим органам непременно потребуется информация об основных средствах с разбивкой по налоговым группам.

О. КАФИДОВА Компания МАГ КОНСАЛТИНГ

М. Правдина. Компьютер под майонезом?

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

Русский путь "Юнилевера". Справка

Для справки: "Юнилевер" был основан в 1930 году в результате слияния двух компаний: голландской "Маргарин Юни" и британской компании "Левер Бразерс", в результате чего были организованы две материнские компании – одна в Лондоне (Юнилевер PLC), а другая в Роттердаме (Юнилевер NV). С тех пор обе компании действуют как единое целое в рамках крупнейшего транснационального концерна "Юнилевер". Концерну принадлежат многие марки престижной парфюмерии: Calvin Klein Cosmetics, Elizabeth Taylor, Elizabeth Arden, Cerutti 1881, Jean Louis Scherrer, Valentino, Chloe. "Юнилевер" также производит замороженные продукты, соусы и оливковое масло. Россиянам иностранный концерн знаком по таким широко рекламируемым продуктам, как маргарин "Рама", майонез "Calve", чаи "Липтон" и "Беседа", мыло "Lux", крем "Pond's", шампуни "Тимотей" и "Сансилк Термасилк", стиральный порошок "ОМО", жидкость для мытья посуды "Санлайт", чистящее средство "Доместос", зубная паста "Пепсодент" и дезодорант "Рексона".

На российский рынок "Юнилевер" вышел в 1991 году. В 1992 году компания открыла первые торговые представительства в Москве и Санкт-Петербурге. Через два года "Юнилевер" приобрел фабрику "Северное Сияние" – одного из старейших российских производителей парфюмерии и косметики. Петербургская фабрика была модернизирована, появились новые производственные линии для выпуска шампуней, дезодорантов, парфюмерной продукции, жидкости для мытья посуды и чистящих средств. В марте 1998 года компания приобрела Московский маргариновый завод, который после модернизации начал выпускать маргарин "Рама" и затем майонез "Calve". В этом же году "Юнилевер" переводит головной офис из Петербурга в Москву и создает новое юридическое лицо – "Юнилевер СНГ". После глобального объединения с компанией CPC Bestfoods в составе "Юнилевер" появился тульский завод, выпускающий знаменитые бульонные кубики "Кнорр". Сейчас в компании работают почти две тысячи человек, ее офисы расположены в 70 городах России и Украины. По словам руководителей российского офиса, "Юнилевер" планирует продолжать инвестиционную деятельность в России.

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

История становления, развития и перестройки бизнеса отразилась и на информационной инфраструктуре. Глобальный партнер "Юнилевера" по управленческим информационным системам – SAP AG. Решения от SAP работают в большинстве из 500 торговых и производственных компаний "Юнилевера" в 160 странах мира. Но скромный по оборотам российский офис начала 90-х на SAP явно не тянул: ни по средствам, ни по задачам, ни по уровню подготовленности персонала. Да и специалистов, способных внедрить и поддерживать такое "тяжелое" решение, в России тогда практически не было.

Департамент ИТ искал такое решение, которое, с одной стороны, позволяло бы готовить отчетность по западным стандартам для иностранных инвесторов, а с другой – вести российский бухучет (который в те годы сильно отличался от мировых стандартов). На рынке тогда было несколько иностранных систем, удовлетворяющих этим требованиям: Scala, Platinum, SunSystems. По ряду причин остановились на последней. Девять лет SunSystems отработала в "Юнилевере" в качестве основной учетной и управленческой системы, на этом ее "трудовой стаж" заканчивается – в следующем году компания планирует перейти на решения SAP.

В лоно корпоративных стандартов

Переход с главным образом бухгалтерской системы на корпоративную систему управления и планирования ресурсами – процедура болезненная. На первый квартал следующего года запланирован официальный старт проекта по внедрению SAP, который займет девять-двенадцать месяцев. Но до сих пор неясно, по какому сценарию будет осуществляться внедрение. "В принципе, есть типовая настройка SAP, которой пользуются в штаб-квартире и большинстве зарубежных представительств "Юнилевера", – говорит глава ИТ-департамента Андрей Князев. – Проблема в том, что люди, которые ее создали и внедряют, серьезно ограничены в ресурсах. И мы, российский офис, пока находимся вне их планируемого горизонта. К тому же неизвестно, насколько эта модель применима у нас. Что бы ни говорили, от российской специфики, той же предоплаты, например, никуда не деться. Кроме того, ни одно представительство "Юнилевера", кроме нашего, дистрибуцией не занимается. Альтернатива – взять за прообраз какую-нибудь другую, недавно внедренную и успешную модель SAP. Желательно, поближе к нашей специфике. Вскоре мы должны определиться".

По оценке Андрея Князева, после внедрения решения от SAP ИТ-бюджет компании возрастет до 1,5-1,7% от оборота (сейчас он меньше 1,5%). Одновременно должны измениться роль и место ИТ-службы в корпоративной структуре. "Сейчас ИТ у нас представлены в классическом виде середины 90-х: в сферу деятельности ИТ-отдела попадает поддержка всего "железа" и программ, их развитие", – рассказывает глава ИТ–департамента. От "классики" в "Юнилевере" будут отказываться. В ближайших планах – перестройка оргструктуры ИТ-департамента. В более далекой перспективе российский офис последует за европейской штаб-квартирой, где сейчас идет процесс централизации управления ИТ и создания структур для организации внутреннего аутсорсинга (in-source). Внутри концерна создана ИТ-компания, обслуживающая потребности всех остальных направлений бизнеса. Тогда и ИТ-отдел "Юнилевер СНГ" будет трансформирован в группу "поддержки" (customer managers), а программисты станут сотрудниками ИТ-компании в рамках концерна. Но произойдет это только через несколько лет.

Пока же в ИТ-департаменте работают 25 человек. Половина занимается поддержкой инфраструктуры по всей территории России: от Петербурга до Камчатки. Вторая половина осуществляет поддержку программных комплексов и ведет разработку новых. В обязанности второй группы, в частности, входит администрирование главного финансового ядра компании – системы SunSystems, с которой взаимодействуют все прочие информационные системы. Этот участок наиболее критичен: в двух блоках SunSystems (SunAccount и SunBusiness) ведется весь бухгалтерский учет, учет продаж, все логистические операции компании, формируется финансовая отчетность по западным стандартам. Все российские заводы и офисы компании работают с единой базой SunSystems, находящейся на серверах в Москве. Самостоятелен только украинский офис "Юнилевера СНГ", но вовсе не по политическим мотивам: исторически другая платформа и версия Sun сделала нецелесообразными затраты на переход к единой системе. Это будет реализовано в рамках перехода к SAP.

Когда советы посторонних приносят пользу

К внешним консультантам по ИТ в "Юнилевере" относятся с настороженностью, предпочитая обходиться, где это возможно, собственными силами. Андрей Князев: "Пока у меня много сомнений насчет того, какие работы можно передоверить внешним компаниям. На днях вот изучал ситуацию с организацией внешнего хостинга и администрирования баз данных для нашего будущего решения от SAP. Специалисты по SAP дороги, и держать их у себя не самое разумное решение. В Европе эту функцию часто передают на аутсорсинг. Но в России я не вижу реальных предложений. Либо предложение совершенно не интересно по финансовым показателям, либо вызывает большие сомнения в плане надежности. К сожалению, рынок таких услуг в России пока не готов, так что дешевле обходиться своими силами".

Однако нельзя все сделать самому. "Я уверен, – говорит глава ИТ-департамента, – что даже западная компания, работающая в России, не сможет обойтись без российского партнера. Например, российский учет и его производные в логистике никто, кроме местной консалтинговой компании, не осилит". Есть российский партнер и у "Юнилевер СНГ". Год назад было принято решение подыскать компанию, которая бы взяла на себя текущую поддержку SunSystems. Рассматривались несколько фирм, в том числе "МАГ КОНСАЛТИНГ". Помимо стандартного пакета услуг специалисты МАГа предложили организовать "Академию пользователей" SunSystems. "Когда мы готовили свое предложение, мы обратили внимание, что одним из узких мест в "Юнилевере" является недостаточный уровень подготовки пользователей, – рассказывает партнер "МАГ КОНСАЛТИНГ" Ярослав Макаев. – В большой компании, где системой постоянно пользуются свыше 200 человек, при текучке хотя бы в 5% место у мониторов SunSystems каждый месяц занимали десять новичков – целый компьютерный класс".

Академия не состоялась: "Юнилевер" как раз принял решение мигрировать на SAP. Но творческий подход МАГ был оценен – компания получила контракт на техническую поддержку SunSystems вместе с пожеланиями обеспечить нормальное функционирование и развитие системы в переходный период. Текущая версия системы была зафиксирована и больше не подлежала обновлению. "Мы выиграли не по ценовым критериям, а только за счет предоставления уникального набора услуг", – считает Ярослав Макаев. Специалистам МАГ потребовалось около двух месяцев, чтобы разобраться с системой, поскольку в результате многочисленных настроек и дописок она далеко ушла от исходной версии. Чтобы понять проблемы пользователей, был проведен опрос более сотни сотрудников "Юнилевера СНГ" в Москве, Санкт-Петербурге и Туле. И для поддержки работы необновляемой системы на нормальном уровне было решено организовать "горячую линию" для администраторов системы и пользователей. "Эта услуга стала дополнительной в рамках контракта, отдельно мы за нее не платили, – вспоминает Андрей Князев. – Позже мы стали вовлекать специалистов МАГ в наши текущие проекты, в частности, в проект по организации хранилища данных в части, отвечающей за интерфейс с SunSystems".

Творческий подход в рамках контракта на поддержку SunSystems консультанты продемонстрировали и при анализе прав доступа пользователей. Потребность в этом проекте возникла накануне приезда аудиторов (из отделов корпоративного внутреннего аудита в немецком и английском офисах "Юнилевера"). Процедура проверки проводится регулярно, обычно раз в год. Особое внимание аудиторы уделяют вопросам безопасности и управления рисками. Среди прочих они оценивают риски, которые вносят в жизнь компании информационные технологии. "ИТ-систем в компании много, все они сопряжены друг с другом, и на их стыках повышается вероятность ошибок или нарушений, – говорит Андрей Князев. – Например, обработка платежей у нас ведется не в SunSystems, а с помощью другого продукта. Получается довольно уязвимая конструкция, и аудиторы обращают внимание на то, какие организационные меры безопасности приняты, какие продукты мы используем, чтобы сократить риск, и т. п. Еще одна болевая точка – права доступа к финансовой информации".

Проблема с анализом прав доступа назрела давно, но эффективно решить ее никак не удавалось. "В SunSystems структуризация прав пользователей, выполнена великолепно, но их внешнее представление очень неудобно для анализа и корректировок, – считает Ярослав Макаев. – Ведь доступ к системе в "Юнилевере СНГ" имеют не 20 сотрудников, а более двухсот, и у многих разные статусы для разных баз данных, модулей, функций, процедур. Распечатанный мелким шрифтом отчет с перечнем всех прав занимает около 700 страниц. Выделенный для анализа настроек системный администратор около месяца пытался вручную проверить права сотрудников. Когда на горизонте замаячил финал этого гигантского труда, в структуре компании произошли изменения, появились новые подразделения, и работу следовало бы начинать заново".

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

Инвестиции в будущее

"Один из проектов, который сделали для нас консультанты, мне особенно нравится элегантностью решения", – рассказывает Андрей Князев. В прошлом году было принято решение автоматизировать учет на тульском заводе, производящем бульонные кубики. Однако в SunSystems нет модуля для автоматизации производственных процессов. Другие пользователи этой системы уже сталкивались с подобной проблемой: так, компания Robertson & Blums, продвигающая SunSystems на российском рынке, разработала специальное производственное приложение для решения такого рода задач. Оно и было предложено "Юнилеверу" для автоматизации производственного учета. Однако, как оценили специалисты, глубокая переработка практически непараметризуемого производственного модуля будет стоить столько же, сколько разработка нового "с нуля". Что не имело смысла в свете грядущего перехода на новую платформу.

От специалистов "МАГ КОНСАЛТИНГ" требовалось дать ответ на вопрос: "Можно ли на базе уже работающих модулей SunSystems обеспечить учет движения сырья и материалов, а также расчет производственной себестоимости продукции?" Проведя множество экспериментов, консультанты ответили "да" – блок "Учет движения сырья и материалов для производства" был реализован на функционале модуля SunBusiness под руководством Алексея Макарова-Землянского, который также был автором программы для анализа прав доступа. Решение получилось довольно дешевым, поскольку для всех производственных операций (в основном это смешивание ингредиентов) уже были готовы справочники номенклатуры, поставок, остатков. Не пришлось создавать заново и интерфейсы со смежным программным обеспечением.

Но главным достижением этого проекта Андрей Князев считает отнюдь не сам факт автоматизации производственного учета. В ходе проекта были досконально разобраны все бизнес-процессы, определена 21 учетная стадия, выделены основные точки контроля. Эта информация должна стать основой для автоматизации производства уже на базе решения SAP. Кроме того, пользователи, которые до начала проекта не работали ни с какой учетной системой, получили необходимые навыки работы с компьютером. "Неявное влияние на предстоящий проект по внедрению SAP состоит в том, что в ходе текущих работ очень многие процессы и объекты выравниваются под смысл и понятия SAP, – отмечает Андрей Князев. – Мы считаем, что провели большую подготовительную работу". С ним соглашается и Ярослав Макаев: "Анализируя параметры настроек SunSystems, можно уже на подготовительном этапе оптимизировать учетные и управленческие процессы, которые затем будут реализованы в SAP".