Весь товар (импортный и докупаемый в РФ) направляют на единый склад в Центральном регионе России. По мере поступления товара на склад дилеров информируют о степени укомплектованности заказа. По распоряжению дилера товары отправляют на его склад в регионе или напрямую конечному покупателю либо передают перевозчику.
Управление холдингом осуществляют на базе годовых планов продаж, еженедельных отчетов по движению денежных средств и план-фактного сравнения продаж. Основываясь на результатах исследований отдела маркетинга, владельцы устанавливают рыночные цены по регионам и нормы прибыли, остающейся в распоряжении дилеров, а также нормы логистических расходов, правила вознаграждения менеджеров по продажам и предоставления бонусов покупателям. Предметом постоянных споров отделов продаж дилеров и отдела маркетинга является уровень рыночных цен, поскольку имеет место типичная для торгового бизнеса тенденция: менеджеры отдела продаж хотят продавать по нижней границе рыночных цен, в то время как отдел маркетинга, представляющий интересы владельцев, настаивает на верхней границе установленного коридора рыночных цен. В течение финансового года допускаются, по согласованию с владельцами, отдельные случаи продажи по ценам ниже установленных годовым планом, в основном в рамках кампаний по продвижению товара.
Подчеркнем, что система продаж в холдинге выстроена под конкретные заявки / заказы покупателей, закупки с целью формирования на складе свободного остатка после ряда неудачных попыток были прекращены еще до начала проекта. В нашем случае это специфика холдинга и выстраиваемой системы управленческого учета.
3. Анализ состояния системы учета и финансового управления на момент реализации проекта
Анализ ситуации, сложившейся к моменту разработки и реализации проекта по внедрению системы управленческого учета и финансового управления, является обязательным, т.к. именно в этот момент взаимосвязи системы становятся наиболее очевидными, а идея и способ решения задачи обретают конкретные очертания. Перефразируя народную мудрость «день год кормит», можно сказать, что анализ проекта и выработанные в ходе анализа решения определяют конечный результат работы.
Система финансового управления
В ходе изучения данного блока было выявлено, что финансовое управление, в сущности, сводилось к еженедельному составлению консолидированного отчета о движении денежных средств в разрезе дилеров. Представление о сроках расчетов с покупателями и поставщиками и соотношении дебиторской и кредиторской задолженностей было весьма приблизительным.
Ни один отчет, формируемый за разумное время, не отражал состояния обязательств покупателей по отношению к оплате. Попытка внедрения автоматизированной системы финансового управления и единообразного ведения учета на базе продуктов семейства 1С оказалась безрезультатной, в распоряжении финансового отдела холдинга осталась лишь система регистрации платежей за рубеж, а у дилеров — различные конфигурации 1С (7.0, 7.5, 7.7), в которых в основном и велся бухгалтерский учет.
Система бухгалтерского и налогового учета
Бухгалтерский и налоговый учет дилеры вели самостоятельно. Информация для составления консолидированной отчетности по холдингу из программ ведения официального учета (бухгалтерского и налогового) не извлекалась ввиду несовпадения его параметров с параметрами управленческого учета. Можно сказать, что бухгалтерский учет и налоговый учет были параллельны управленческому учету и не пересекались с ним. Бухгалтерские службы, включая финансовую службу холдинга, были одними из самых многочисленных.
Система CRM
Управление взаимоотношениями с клиентами было реализовано в программном продукте известного на рынке производителя систем документооборота. В этой же программе осуществлялись складской учет и контроль сроков выполнения заказов. На момент реализации проекта такая архитектура однозначно устарела, однако следует учесть, что CRM-система внедрялась в те времена, когда у 1С существовала только не модифицируемая пользователем конфигурация 6.0, а выбранный программный продукт был предназначен в основном для обеспечения документооборота, таким образом, архитектура позволяла пользователю собственными силами разрабатывать учетные модули. Главная цель, ради которой внедрялась система CRM, — ведение учета договоров с покупателями и спецификаций к договорам, регулирующим каждую поставку. Кроме того, система позволяла инженерным службам дилеров разрабатывать спецификации до уровня номенклатуры поставщиков, а отделам сопровождения договоров и логистики — вносить условия и сроки поставок с последующим контролем и учетом дат их фактического выполнения. Таким образом, система CRM была самой развитой в холдинге системой учета, связывающей воедино различные службы — от продавцов до логистов и склада, а также центральную закупочную фирму и дилеров, — на едином сервере под контролем владельцев. Тем не менее получить исчерпывающую финансовую информацию о фактическом состоянии дел из этой системы было невозможно, а достоверность проводимого в ней складского учета вызывала постоянные нарекания. Систему управленческого учета пришлось бы «подчинить» системе CRM, поскольку владельцы и менеджмент опасались менять худо-бедно работающую систему на новую. Однако в процессе реализации проекта необходимость замены блока CRM на такой же, но функционирующий на единой платформе с системой управленческого учета стала для владельцев и большинства менеджеров очевидной.
Важным оказалось то, что номенклатура товаров как ключевой элемент учета велась и поддерживалась именно в системе CRM. При этом было выявлено, что номенклатура товаров, закупаемых у поставщиков, не всегда совпадала с номенклатурой продаваемой продукции. Такая ситуация была обусловлена стадией развития бизнеса: из простого оптовика холдинг превращался в поставщика готовых решений, поэтому большое количество сделок с покупателями могло содержать номенклатуру услуг по созданию промышленных систем и блоков из продукции от разных поставщиков либо комплектов такой продукции, выступавших для покупателя как один объект. Подобный расклад стал серьезной проблемой для системы учета именно импортного товара, поскольку во всех сделках (поставках, накладных) товар, следующий транзитом от границы, должен иметь определенный номер грузовой таможенной декларации (ГТД).
Складской учет
Складской учет велся в двух плоскостях: в системе CRM — для менеджеров отдела продаж, отдела логистики и отдела сопровождения договоров и на бумажных ведомостях — для сотрудников склада. Сопоставить эти два направления учета можно было лишь приблизительно и в ходе мучительной инвентаризации, и то не до конца.
Как показала практика, старая система допускала грубейшие ошибки, приведшие к значительным финансовым потерям. Большой минус ведения складского учета в системе CRM заключался в том, что менеджеры манипулировали аналитическими параметрами поставки, например обозначая партию как предназначенную другому дилеру или как ушедшую со склада (чего в действительности не происходило). В таких условиях, а также в связи с тем что работники склада оперировали не данными инвойсов и накладных, а данными упаковочных листов, возникала ситуация двойного учета. Был необходим партионный учет номенклатуры, что означало привязку каждой единицы товара к конкретной партии от поставщика и к конкретному заказу покупателя одновременно. Имеющаяся система CRM позволяла видеть отдельные позиции, но не давала возможности проконтролировать достоверность полученной информации.
Логистика
Благодаря усилиям и профессионализму сотрудников и руководства отдела логистики, а также тому факту, что в сиcтеме CRM учитывались логистические параметры (сроки и адреса доставки), контроль за движением товаров находился на надлежащем уровне. Однако существующая система логистики не устраивала владельцев бизнеса, которые считали «логистическими» проблемы взаимоотношений с поставщиками, возникающие из-за несовершенства системы взаиморасчетов (точнее, из-за почти полного ее отсутствия): система учета не позволяла досконально отслеживать платежи в разрезе поставок, взаимозачеты, проплаты одних дилеров за других, проплаты через прочих контрагентов и т.д. Немаловажным для целей учета был тот факт, что владельцы требовали учитывать логистические и иные прямые расходы, касающиеся сделок с контрагентами. Значительно затрудняла учет следующая ситуация: в инвойсах поставщиков вспомогательным компонентам основного товара давалось общее название, например kit (набор, комплект), соответственно, эта строчка в инвойсе получала при растаможивании номер ГТД. В то же время конечные покупатели часто требовали развернутого перечисления компонентов kit в счетах и сопроводительных документах (накладных, счетахфактурах), но проставление такого же номера ГТД, как у kit, для каждого компонента могло вызвать претензии таможенных и налоговых органов. Кроме того, часть компонентов набора могла быть поставлена другому клиенту, т.е. kit мог быть разделен в продажах.
Информационные технологии
В холдинге функционировал центральный сервер, расположенный в головном офисе, на базе сервера была размещена система CRM, доступная дилерам в регионах. В ходе реализации проекта качество связи было доведено до хорошего, позволяющего сформировать единую базу системы ERP-класса. Дилеры имели собственные серверы, доступ к которым можно было осуществить из центрального офиса (для просмотра учетных баз дилеров). В свое время реализовать распределенные учетные базы 1С на основе такой архитектуры не удалось, но, как показал анализ, не по техническим, а по организационным причинам. Следует отметить, что в наше время IT-инфраструктура и квалификация персонала ITотделов позволяют без особого труда решить задачи, касающиеся ведения учета в системах ERPкласса (по крайней мере 1С) на центральном сервере территориально удаленными пользователями. Не представляет особых проблем реализация доступа по каналам VPN и через Wi-Fi.