Шанс на транзакционный учет

Когда начинать

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

• несовпадение аналитики к данным о транзакциях, представляемых различными подразделениями. К примеру, программный комплекс по учету продаж в ритейле настроен по подразделениям, административные расходы в бухгалтерии — на основе валовых показателей, а руководство компании высказывает желание видеть расчеты на основе АВС (activity-based costing);

• критичное количество локально используемых информационных систем (иными словами, проблема copy-paste — копировать-вставить). Например, продажи сети магазинов одежды учитываются в одной программе; склад — в другой; бюджетирование ведется средствами Excel, равно как и учет валютных операций, связанных с импортом; зарплата — в 1 -С зарплата и кадры 7.7 и т. д. В этом случае, чтобы ответить на вопрос генерального директора о том, каковы результаты «план-факт» анализа себестоимости проданных товаров, приходится «копипейстить» из нескольких систем в одну (чаще всего Excel) огромное количество данных, которые обычно имеют несовпадающие аналитические срезы;

• отсутствие у головной компании детальной информации о деятельности подразделений, кроме финансовой и управленческой отчетности. Это — обычная проблема компаний начиная со среднего размера, которые имеют географически удаленные подразделения или даже достаточно большое количество подразделений в локальных пределах. Яркая иллюстрация: головная компания украинского пивного холдинга получает от производственного подразделения комплект бюджетных отчетов и основные формы бухгалтерской отчетности. На стадии предварительного анализа у головной компании возникли вопросы к внеплановому уменьшению транспортно-заготовительных расходов. Запрос от финансового директора «летит» к его же заместителю, отвечающему за контроль подразделений; от него — к директору подразделения; далее — к главному бухгалтеру подразделения. Хорошим результатом этого запроса будет появление в процессе уже post mortum («посмертного», то есть после принятия) анализа бюджета: «Евгений Степанович, так это потому, что мы добились от поставщика DDP (по ИНКОТЕРМС — «поставка с оплатой пошлины», где продавец несет все расходы и риски по транспортировке товара)».

Все это не было бы перечнем проблем, если бы компания имела неограниченное время на принятие решений. Чтобы ликвидировать несовпадение аналитик, нужно создать детализацию на стадии анализа данных. Необходимость в переносе данных из одной системы в другую стала бы еще одной нагрузкой на IT-отдел. А отсутствие детальной информации ликвидируется через запросы на необходимые данные и создание внутренней системы прямых запросов «начальник-исполнитель». Можно было бы, если бы не фактор времени. Пусть сегодня в Украине целые отрасли находятся в стадии становления, и конкуренция низка, пускай названные проблемы — проблемы большинства. Но современный бизнес все больше характеризуется как раз сокращающимся временем на принятие решений и, следовательно, возрастающими требованиями к полноте и пропускной способности информационной системы предприятия. Логично, что в большинстве случаев инициатором проекта внедрения ERP становится финансовая служба, более других ограниченная временными рамками (в вопросах подачи отчетности налоговым, статистическим и другим государственным органам, а также — руководству и владельцам компании). Важно, чтобы финансовая служба продолжила сохранять лидерство и участие на всех стадиях проекта внедрения, иначе инициатор может оказаться на обочине изменений.

Что предусмотреть в контракте

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

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

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

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

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

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

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

2. Оговорке об обязательном руководителе проекта по внедрению внутри компании и подчинении ему всех участников проекта.

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

В качестве операционного управляющего проектом целесообразнее назначать представителя компании, а не привлекать на временной основе специалиста из компании-вендора. В последнем случае руководитель проекта будет поставлен на пересечении интересов вендора и клиента, что чаще всего только вредит проекту. К тому же такой специалист будет отлично знать программу, но не потребности компании, и лучше понимать аргументы внедряющей организации. Это кажется малой проблемой — потребности можно пояснить, интересы соблюсти. Но различия могут быть значительными. К примеру, один из моих проектов частично приостановился на 1,5 месяца только потому, что руководитель проекта (сообразуясь с информацией от вендора и будучи сам IT-специалистом) счел работы по фронт-офису завершенными, в то время как бухгалтерия компании считала иначе. В понимании руководителя проекта и внедряющей организации термин «работает» означал работоспособность программного кода и как максимум необходимость настройки: «включить функцию расчета», «добавить расчет НДС», «настроить расчет себестоимости по подразделениям» и т. д. В понимании бухгалтерии «работает» — значит можно учитывать транзакции, и результат будет соответствовать проектным требованиям. С учетом того, что проект осуществлялся в пяти странах одновременно, на ликвидацию последствий «коммуникационного сбоя» ушло более месяца.

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

3. Принятии плана-графика проекта и сметы внедрения.

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

4. Описании учебной и справочной документации — общего вида и примеров учебных материалов, а также процедуры их тестирования.

На этапе внедрения обучение проходят лишь так называемые ключевые пользователи, обычно руководители подразделений или заместители, которые впоследствии должны проводить обучение остальных специалистов. Для быстроты и безошибочности дальнейших обучений учебные материалы должны быть максимально наглядными и полными. При наличии качественных учебных материалов функциональность системы можно изучать по мере необходимости. По моему мнению, нет ничего более наглядного, нежели видеоинструкции с аудиосопровождением, полный комплект которых размещен на внутреннем сервере компании. Это решение довелось видеть на практике — компания постановила, что данные о текущих покупках подразделений следует вводить в центральном офисе, где было создано соответствующее подразделение. В компанию одновременно на неполный рабочий день пришло несколько студентов, которые вместо специального курса обучения получили следующие видеоинструкции — «как ввести накладную на покупки сырья»; «как создать новый необоротный актив»; «как исправить сохраненную ошибку «неверное подразделение» и прочее, а также пару дней работы на тестовой базе (это несложно сделать силами программы Camtasia Studio, можно пойти и более консервативным путем — «скрин-шоты» и текстовые описания). Лучше добиться этого от вендора путем внесения требования о детальном руководстве пользователя в устав проекта, причем таким образом, чтобы на основе данных материалов проходило обучение ключевых пользователей. Это позволит внести в обучающие материалы необходимые изменения. Столь же важно изначально соблюсти принцип Майкла Портера — «все в сеть». Вся команда по внедрению должна обладать поразительной пропускной способностью, не задерживая даже на день решения ни одной возникающей проблемы. Как это будет сделано — удел конкретного проекта. Оптимальным является оснащение участников проекта ноутбуками и мобильным выходом на сеть по GPRS с помощью конференц-связи в Skype. Это даст им возможность обсудить возникший сбой при компиляции отчета о прибыли и убытках, а с помощью доступа к программе по серверу терминалов устранить его быстрее, чем при решении обычным способом. Именно проведением сначала ряда совещаний, посвященных сбору данных о возникших в прошлом месяце проблемах по проекту. А затем решения всех проблем в ходе итогового совещания. В данном случае первый вариант не просто экономит время, но и экономит деньги (достаточно взглянуть на почасовые ставки вендора; вспомнить о дополнительно нанятых на время параллельной работы сотрудниках старой и новой системы и т. д.).

Как избежать двойной оплаты «работоспособного функционала»

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

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

Не стоит забывать об отличиях в системе учета и налогообложения. Если ERP внедряется в Швейцарии, где отсутствует налоговый учет, а управленческий укладывается в рамки детализации к финансовому учету, то внедрение пройдет априори более гладко, чем в Украине. Ведь в нашей стране мы имеем три раздельных системы учета — налоговый, финансовый и управленческий. И если финансовый и управленческий учеты возможно сблизить весьма существенно (правда, из-за отсутствия общепринятой практики это становится непростой задачей), то налоговый — нельзя. С этим можно сосуществовать, что и делает все украинское бизнес-сообщество, но при внедрении ERP-системы лучше начинать с более мономерного учета (например, с казахского, швейцарского или российского). Если в других странах процесс прошел успешно, то в Украине речь пойдет о внедрении стандартного функционала системы с доработками под конкретную компанию. Проще, дешевле, быстрее. И лишь один подводный камень — стандартный функционал.

Учесть требования всех ключевых пользователей

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

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

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

К сожалению, обычная практика далека от этого идеала. Чаще всего каждое подразделение готовит собственные требования к функциональности системы самостоятельно. Результат — как минимум затягивание проекта, что хорошо иллюстрирует следующий пример. В упоминавшейся ранее ресторанной сети внедрение функционала учета продаж (информация о транзакциях входила в систему из POS-терминалов) логично отнесли к фронт-офису. Было внедрено много улучшений: автоматизирована информация о реальном количестве клиентов и среднем чеке; автоматизирована передача внутренних заказов на изготовление блюд; увеличена детализация информации о нестандартных продажах (скидки, подарки и т. д.) и многое другое. Но финансовая служба в эти работы не была вовлечена. Только после подписания позитивных документов о завершении работ по внедрению учета продаж и в процессе обучения специалистов финансовой службы функционалу компиляции основной финансовой отчетности выяснилось, что записи налогового, бухгалтерского и управленческого учета формируются неверно. В финансах и налоговом учете в расходы включалось питание персонала без начисления налога на доходы физических лиц. В управленческом учете неверно учитывались нестандартные, например, акционные продажи. О бухгалтерии просто забыли, изменяя стандартный работоспособный функционал. Собственно, проблема сама по себе была несложной и требовала всего нескольких часов работы. Но специалисты вендора по фронт-офису уже работали над другими проектами, а у финансовой службы на это вообще не было предусмотрено время. В результате функционал полностью заработал лишь через четыре (!) месяца после выявления проблемы.

Всеобъемлющая роль финансовой службы

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

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

Ключевым словом в этом перечне является «транзакция». От финансов в процессе внедрения ERP требуется построить транз-акционную систему учета, которая позволяла бы фиксировать информацию о любых изменениях в состоянии или деятельности компании. Противопоставьте это необходимости вводить один и тот же документ по три-пять раз при наличии нескольких информационных систем. Ожидаемая прибыль от незавершенных операций (к примеру, длящаяся перевозка у логистической компании) является событием для учета по международным стандартам финансовой отчетности, но совершенно необязательно — для бюджетного учета компании. Предоплата за работы изменит лишь состояние расчетов в МСФО и НСБУ (учете по национальным стандартам бухгалтерского учета), но изменит налоговые обязательства компании. Списание легкового автомобиля, используемого продажами, может изменить лишь количественный бухгалтерский учет (при условии нулевой остаточной стоимости), но привести к изменениям в бюджетировании (где, предположим, покупка нового ожидалась в более отдаленном будущем). Примеров может быть множество, но все они имеют одну общую черту — в рамках ERP любая транзакция должна фиксироваться с возможностью стать событием в любом виде учета компании. Только в этом случае в результате внедрения финансовая служба (а вместе с ней — вся компания, ее руководство и владельцы) получает единый информационный инструмент. С учетом вышесказанного, а также потому, что финансовая служба обычно обладает наилучшей культурой работы с базовой документацией, она должна участвовать во внедрении всех функционалов системы. В практическом применении это позволит выйти на централизацию потоков документов, информации и процесса ввода данных в систему с помощью создания единого подразделения (см. схему «Одним потоком»).

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

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

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

Об авторе:

Виктор Прудковских, главный бухгалтер "Панальпина Уорлд Транспорт".

Родился в 1978 г. Имеет два высших образования: в области финансов и в области права (КНЭУ). 2007 г. — по настоящее время: главный бухгалтер компании «Панальпина Уорлд Транспорт» (логистика — перевозки, таможенное оформление, проекты). 2005-2007 гг.: главный бухгалтер компании «Чили-Пицца» (сеть ресторанов средней категории). 1995-2005 гг.: бухгалтер, затем главный бухгалтер компании «Лелека» (розничная торговля продуктами питания).
Опыт проектов в строительном бизнесе, оптовой торговле изделиями медицинского назначения.
Автор ряда статей в журнале «Комп&ньоН».

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