Управленческий консалтинг

Контакты

Россия 109240, Москва, ул.Верхняя Радищевская д.7 стр.3, тел. +7(495)2323624
[email protected]
Казахстан 010000, Астана, ул.Кунаева 14/1, ЖК Нурсая, офис 1, тел. +7(7172)794970, +7(701)5222223
[email protected]

На правах рекламы

помогаем зарегистрировать ооо под ключ

RSS-материалВнедрение ERP

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

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

Игорь Аверчев, старший менеджер МАГ КОНСАЛТИНГ

Статья опубликована в журнале «Технологии строительства» (№3, 2005) 

Выбор наших читателей

* Как строить систему управленческого учета
* Диалоги об управленческом учете
* Управленческий учет. Статья 2
* Введение в управленческий учет
* Курс на МСФО

  


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

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

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

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

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

Самыми простыми в эксплуатации, самыми дешевыми и самыми распространенными программными продуктами, используемыми при подготовке отчетности, являются табличные процессоры. К ним относятся 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

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

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

Статья опубликована в журнале «Профессиональное строительство», №5, 2004

Выбор наших читателей

* От универсальных технологий управления – к приложениям для строительной отрасли
* Balanced Scorecard для девелопмента недвижимости: особенности, проблемы, подходы
* Программные продукты для промышленно-строительных холдингов
* Действовать быстрее, чем другие думают


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

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

В наш бурно развивающийся век информационных технологий у всех на слуху системы класса 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 года).

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

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

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


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

Компьютер под майонезом?

Мария Правдина

Статья опубликована в журнале «Секрет фирмы», №10, 2003 

Выбор наших читателей

* Предисловия к русскому изданию книги Р. Каплана и Д. Нортона "Организация, ориентированная на стратегию"
* Новая экономическая революция
* Родился в одной семье немой мальчик...


Наверное, каждая хозяйка знает майонез 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".

 

Я. Макаев, Е. Сарданашвили "Бизнес на внедрении. Роль консалтинга при внедрении ERP-систем"

Бизнес на внедрении. Роль консалтинга при внедрении ERP-систем

Ярослав Макаев и Елена Сарданашвили, консультационная компания МАГ КОНСАЛТИНГ

Статья опубликована в журнале "Технологии бизнеса. Connect!", № 9, 2003 


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

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

Простой пример. Рабочему поручили тачать гайки. Он является мастером своего дела и гайки тачает ловко и быстро. Хорошо? Да. Но какой результат? Со временем может оказаться, что такое количество гаек, которое он произвел, никому не нужно, занимает место на складе и вместо прибыли создает затраты. При этом для самого рабочего ситуация предельно логична: чем больше гаек, тем больше денег. Однако на уровне руководства компанией, возможно, наоборот: выгоднее платить рабочему зарплату и заставлять его временно гайки не делать или делать их медленнее.

Точно так же проект по внедрению ERP-системы нельзя рассматривать только на уровне ИТ-отдела и ИТ-специалистов. Решение должно приниматься на уровне руководства компании и иметь стратегическое значение.

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

Вниз и вверх по пирамиде

Управленческую структуру компании можно представить как пирамиду.

Рис. 1

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

Сформулировав цель, необходимо описать векторы движения, показывающие, каким образом компания достигнет своей стратегической цели. Отдельные «стрелочки» могут быть разнонаправленными, но суммарный вектор должен вести к цели. Такие векторы называются ключевыми показателями деятельности (KPI). После того, как они сформулированы, к ним можно привязать количественную оценку. Например, сам по себе показатель удовлетворенности зарплатой достаточно субъективен. Однако можно выделить некий количественный или качественный критерий, который конкретизирует информацию, делает ее полезной с управленческой точки зрения: «Сотрудники довольны зарплатой? Да/нет», или: «80% сотрудников довольны зарплатой».

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

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

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

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

Условия успеха

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

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

Как правило, техническое задание составляют консультанты, с участием ИТ-специалистов компании. После этого можно приступать к внедрению.

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

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

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

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

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

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

Светофор для директора

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

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

Рис. 2

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

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

Ну и что? Дальше что?

Система внедрена. Цель достигнута? Конечно, но почивать на лаврах рано. Как и навсегда прощаться с вашими консультантами.

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

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

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

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


М. Горский "Мы пойдем своим путем..."

"Мы пойдем своим путем..."

Микаэл Горский

Статья опубликована в журнале "Компьютер Пресс", №7, 1997 г.


О чем эта статья

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


Компания

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

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

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

Первый блин

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

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

Развитие системы шло эволюционным путем. Через полгода непрерывного совершенствования программы созданная рабочая книга Excel уже включала в себя шесть таблиц - таблицы товаров, заказчиков, балансов заказчиков, формы накладной, счета/инвойса, прайс-листа. В процессе работы система использовала еще четыре рабочие книги, каждая из которых состояла из двух таблиц. Для организации пользовательского интерфейса была написана программа на Visual Basic, организующая запросы к пользователю для ввода данных. Объем рабочего файла составлял два мегабайта, не включая собственно данные.

Созданная система выполняла четыре основные функции:

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

В последней версии система учитывала следующие показатели:

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

Система позволяла вести продажи как товаров на складе, так и товаров из прибывающей партии.


Первый урок

Опыт компании "Эникей" показал, что Excel как инструмент для создания корпоративных учетных систем обладает достоинствами:

  • простота пользования таблицей,
  • популярность,

и недостатками:

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

Второй блин

Неудивительно, что в конце концов автор разработки Илья Ягодин принял решение полностью переписать систему, реализовав ее на этот раз в СУБД.

Выбор инструмента разработки был недолог. Access победил, ибо предоставлял возможность конструировать базы данных, связи между ними и запросы к ним с помощью "мышки", без изучения SQL. Свою роль сыграло и то что Access позволяет с минимальными усилиями строить пользовательский интерфейс, входные и выходные формы. Сравнения с аналогичными средствами (FoxPro, Lotus Approach) были исключительно умозрительными и привели к безусловной победе Access.

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

При разработке системы не нашли применения ни структуры данных Excel-версии, ни использовавшаяся в Excel-версии программа на Visual Basic. Все создавалось заново.

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

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

Работающая сегодня версия системы реализует следующие задачи:

  • Учет товаров на складе.
  • Учет заказанных, оплаченных и ожидаемых товаров.
  • Учет истории заказчиков (оборот по сделкам, предпочтения по группам товаров), ведение баланса взаиморасчетов.
  • Печать счетов, накладных, рассылка их по факсу. Также печатаются приходные ордера, прайс-листы (5 видов), ценники.
  • Печать складских справок, выписок по товарам на складе и в пути.
  • Анализ движения товара.
  • Расчет оптимальной цены реализации для различных сегментов рынка.
  • Экспорт и импорт данных в другие Windows программы (Excel, Word).
  • Автоматическое формирование заказа на поставку, печать заказов на английском языке.

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

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


Второй урок

При переносе системы в среду Access предполагалось решить три проблемы:

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

Достижение этих задач можно оценить следующим образом:

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

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

Вначале система работала быстро. Скорость работы начала резко падать как только в системе появились новые функции, а записи о товарах и контрагентах пополнились новыми полями. Через полгода работы система была заново переписана с Access 2.0 на Access 7.0, при этом программа была оптимизирована и ставшие избыточными модули были удалены. Несмотря на предпринятые усилия, система отличается "задумчивостью" даже при выполнении несложных операций. Компьютеры, на которых система выполняется сегодня - это Pentium-133 с 32 мегабайтами памяти. По оценке пользователей системы, скорость работы сравнима со скоростью работы "старой" Excel-версии на 486dx4-100 компьютерах с 16 мегабайтами памяти.

Сегодня разработчик мечтает о том, чтобы переписать систему (ее клиентскую часть) на каком-либо из языков программирования (например, C++) и соединить ее с СУБД среднего класса.

НО: среди разговоров о выборе между C++ и Delphi 2.0 проскользнуло: "А нет ли готовой системы, удовлетворяющей нашим потребностям?".

То, что этот вопрос зазвучал в устах российского программиста, обнадеживает:


Третий урок (мнение консультанта)

Рассказанная история не оригинальна. Многие российские компании пользуются учетной (а зачастую и бухгалтерской) системой собственного изготовления.

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

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

А. Гершун "Сделайте ваш выбор"

Сделайте ваш выбор

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

Материал опубликован в журнале "БОСС", № 2, 1997 г.

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

Придется ли менять используемую бухгалтерскую программу, если ваш бизнес расширится в несколько раз?

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

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

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

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

На сегодняшний день на рынке бухгалтерских программ более 600 предложений, из которых около 50-ти пакетов предназначены для автоматизации средних предприятий. Это очень большой рынок. Если оценить сумму затрат на автоматизацию бухгалтерии на одного 1-го сотрудника в 50 долларов - что-то среднее между $10 (стоимость пиратского CD-ROMa) и $1,000 (стоимость затрат при внедрении большой интегрированной системы), то российский рынок бухгалтерских программ можно оценить как минимум в 3-4 миллиарда долларов: 90 млн. - работоспособное население России х $50 (средняя сумма затрат на автоматизацию бухгалтерии одного сотрудника компании) = $4.5 млрд. долларов.

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

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

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

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

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

Иногда, из-за высокой стоимости программ или по другим причинам (соотношение стоимости программ и заплаты сотрудников бухгалтерии обычно не в пользу последних) средние компании используют программы, предназначенные для малых предприятий. Это чревато повышенными трудозатратами бухгалтеров при ведении учета и дополнительными рисками. Маленькие программы не рассчитаны на обработку больших объемов данных, и в какой-то момент они могут начать терять информацию или полностью выйти из строя (“переполниться” и “рухнуть”). Типичная ситуация, когда компания использует бухгалтерскую программу очень редко, так как она переполнена, и есть ощущение, что она рассыплется в любой момент. Кроме того, программы для малых предприятий обычно позволяют работать лишь с основными бухгалтерскими операциями и обрабатывают недостаточно аналитических данных, чтобы провести полноценный анализ деятельности предприятия.

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


Что мы приобретаем и что теряем, приобретая новую бухгалтерскую программу?

 

ПриобретаемТеряем
деньгиПовышение точности финансовой и оперативной отчетности (улучшение
управления предприятием);

Уменьшение потерь вследствие улучшения оперативного учета;

Уменьшение бухгалтерского персонала и, следовательно, снижение фонда зарплаты;

Снижение затрат на проведение аудита.

Стоимость программы;

Стоимость проекта внедрения;

Стоимость гарантийного обслуживания;

Стоимость текущих консультаций;

Стоимость обучения сотрудников;

Стоимость новой компьютерного оборудования, ее установки и поддержки;

Зарплата специалистов, которые будут поддерживать систему.


время

Экономится время на получение информации, необходимой для анализа бизнеса;

Уменьшается время, необходимое для обработки некоторых документов;

Уменьшение затрат времени на обмен учетной информацией внутри компании.


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

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

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


Что надо для установки бухгалтерской системы?

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

Что является определяющим при построении системы? Выбор технологии (клиент-сервер, Windows, Oracle и т.п.) может только гарантировать рамки технических характеристик (объем, производительность), потенциальную совместимость и потенциал развития; выбор аппаратуры определяет конкретные характеристики (производительность, надежность) системы; и только выбор программы может определить будет ли система вообще работать на вашем предприятии.

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

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

КомпанияВнешние подрядчики
Руководство компанииПоставщик программы
10pixel_white_spacer.gif (41 bytes)Руководить выбором системы;

Руководить проектом внедрения;

Найм или выделение сотрудников, сопровождающих систему.

10pixel_white_spacer.gif (41 bytes)Поставить программу;

Обеспечить техническое сопровождение;

Проводить консультации;

Обучить сотрудников.

Бухгалтерия,
автоматизируемые отделы
Консультант
10pixel_white_spacer.gif (41 bytes)Предоставить описание бизнес-процессов

Сформулировать требования к системе

10pixel_white_spacer.gif (41 bytes)Обследовать информационные потоки предприятия;

Оказать помощь в выборе системы;

Внедрить программу.

Отдел автоматизацииИнтегратор,
поставщик аппаратуры
10pixel_white_spacer.gif (41 bytes)Обеспечить поддержку системы.10pixel_white_spacer.gif (41 bytes)Установить аппаратуру;

Обеспечить гарантийное сопровождение.

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


Сколько стоит?

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

Стоимость программы = X (от $1,000 до $50,000).

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

Стоимость проекта внедрения - от 1Х до 7Х (этот коэффициент возрастает для больших систем).

Скрытые внутренние убытки (зарплата отвлекаемых сотрудников, питание консультантов и т.п.) - 1-2Х.

Кроме того, учтите ежегодную плату за гарантийное сопровождение программы (новые версии, горячая линия и т.п.) - примерно 20% от стоимости программы и еще зарезервируйте примерно 10-20% на консультационное обслуживание, которое может потребоваться для дополнительной настройки системы, например, при реструктуризации компании или при изменении законодательства.

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


--------------------------------------------------------------------------------
Правильно работающее программное обеспечение

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

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

Надежность программ является значительным критерием при выборе программы. Современные технологии позволяют пережить внезапное выключение компьютера без потерь. Одной из надежных платформ для программ является база данных Btrieve. В мире эта база данных занимает около 80% среди финансовых приложений (например, программы Platinum и Scala). Некоторые российские пакеты также разработаны на Btrieve (это Галактика, RS-Balance).

Разработка бухгалтерских программ, как никакое других требует обязательного наличия команды тестеров. Любая пропущенная ошибка дошедшая до пользователя грозит неприятными результатами. Это еще хорошо, что в бухгалтерии еще не утрачен инстинкт недоверия, и большая часть компьютерных результатов проверяется вручную. В хороших компаниях так и делают: идут на дополнительные расходы. Например, компания Microsoft произвела революцию в качестве продуктов имея по одному тестеру на одного кодировщика, вместо обычного для Запада соотношения 1 к 5 (или 0.01 к 5 в России).

"Тише едешь - дальше будешь!" Вот она оправдывающая себя на все 100% американская философия разработки американских программ (и много чего другого, что известного своим высоким качеством). Этот принцип применяется и к разработке бухгалтерского программного обеспечения.

"Работа - это подвиг!" - для многих из нас - это основополагающий подход к работе, который позволяет постоянно обгонять другие страны, но неизменно приходить к финишной прямой в конце (если вообще приходить к финишу?). Многие программы выполнены по этому принципу, и они могут обладать прекрасными дизайном, использовать новейшие супертехнологии, но при этом напоминать помесь арифмометра Паскаля с нестабильным синхрофазотроном, использовать который хуже простого калькулятора.

Типична следующая ситуация: “Мы недавно переехали в новый офис, и у нас часто отключают электричество. После первого же броска программа отказалась работать, и нам пришлось восстановить информацию из резервной копии (которая слава Богу у нас была!). Целый день работы был потерян.”


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

Западные или российские системы?

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

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

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

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

Западные пакеты

Российские пакеты

Системы давно используются на Западе (Scala начиная с 1978, Platinum с 1984), то есть в среднем 15-20 летВ среднем история российских программ не превышает 5-8 лет (Галактика с 1987, Инфин с 1988).
Большое количество инсталляций в мире и относительно небольшое в России: Platinum 40,000 (около 100 в России); Scala 12,000 (около 250 в России); Sun 10,000 (около 100 в России)Большое (для российского рынка) количество инсталляций в России: Галактика - 1,500
Известны западным инвесторам.Знакомы российским бухгалтерам.
Программы могут готовить отчеты по западным стандартам. Фирмы обладают технологией и опытом установки систем, ведущих двойной учет.Некоторые программы (например, Галактика, ИНОТЕК) также обладают возможностью получения западной отчетности.
Наличие многоязычных версий (как минимум на русском и английском). Некоторые программы предоставляют возможность кроме того немецкий, голландский, испанский и французский языки).Практически все программы работают только на русском языке.
Устоявшиеся программы с устоявшимся интерфейсом и жесткими бизнес-процессами.Программы интенсивно развиваются и изменяются. Легко поддаются модификации.
Жесткие бизнес-процессы не всегда применимы в российском бизнесе.Изначально разработаны для российского бизнеса.
Так как пакеты писались давно, то имеют тяжелый непривычный интерфейс.Интерфейс привычен, так как используется российская бухгалтерская терминология.
Относительно немного ошибок (процессы тестирования программ пока заграничных фирмах пока поставлены лучше).Качество программ со временем улучшается.
Обычно полные интегрированные пакеты.Не всегда есть полные решения.
Высокая стоимость программы, внедрения и сопровождения.Стоимость российских систем обычно ниже.
Длительный процесс внедрения обычно требует наличия дорогих консультантов.Многие пользователи внедряют программы самостоятельно без помощи консультантов.