Управление группой компаний в 1С:Управление Холдингом

Об авторе

В 1997 году закончил Волгоградский Государственный Университет, специализация «Прикладная математика и мат. методы в экономике».
Более 10 лет проработал руководителем ИТ подразделений крупных промышленных предприятий.

В том числе:

• Волгоградский региональный филиал торговой сети «Пятерочка», Руководитель ИТ отдела,
• Волгоградский мясокомбинат, Заместитель генерального директора по ИТ,
• Волгоградский судостроительный завод, Заместитель генерального директора по ИТ,
• Группа компаний Новокор (производство и оптовая торговля сантехникой и обоями), Директор ИТ,
• Группа компаний Акцент (многофпрофильный промышленный холдинг), Директор ИТ,

С 2014 года работает руководителем корпоративных проектов во Внедренческом центре «Раздолье», заказчики проектов дочерние предприятия Роснано, Ростех, ТехМаш.

Специализация: автоматизация управленческого учета (производство, продажи, логистика, бюджетирование).

В 2014 году компания «1С» выпустила решение для комплексной автоматизации предприятий крупного масштаба «1С:Управление холдингом 8».
До этого момента у компании «1С» не существовало собственных решений, которые позволяли бы автоматизировать весь спектр задач, которые встречаются при организации учета в группах компаний.

Перечень этих задач следующий:

• Организация единого информационного пространства через интеграцию учетных систем предприятий, входящих в холдинг;
• Организация централизованного казначейства;
• Централизация закупок;
• Стратегическое управление холдингом:

а. Планирование,
б. Контроль результатов,
в. Составление консолидированной отчетности по группе компаний, в том числе с использованием стандартов МСФО.

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

Отличительной особенностью программного решения компании «1С» является привлечение к проектированию системы специалистов международной компании «Ernst&Young», а также более зрелый и комплексный подход к вопросу учета в группах компаний, который выражен в том, что «1С:Управление холдингом» изначально ориентируется на то, чтобы служить центром консолидации информации из разнородных учетных систем территориально удаленных предприятий с разнообразными видами деятельности.

Предполагается, что при организации учета в холдинге у отдельных предприятий могут использоваться не только учетные программы компании «1С», но и программы других производителей, а также возможен сбор данных с предприятий, которые ведут учет с использованием MS Excel. И все это многообразие учетных данных «1С:Управление холдингом» способно преобразовать в единую стройную систему учета, планирования и контроля.

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

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

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

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

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

На кого ориентированно это руководство:

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

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

• Бухгалтерский и налоговый учет в группе компаний,
• Организация корпоративной отчетности по стандартам МСФО,
• Работа с проектами в «1С:Управление холдингом».

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

Для того, чтобы не отвлекаться на технические детали, предположим, что все предприятия группы компаний используют в работе «1С:Бухгалтерию» для ведения бухгалтерского и налогового учета, а также MS Excel для ведения управленческой отчетности. Это упрощение никак не скажется на качестве примера, так как проблемы с которыми придется сталкиваться при интеграции других учетных систем с «1С:Управлением холдинга» будут схожи с проблемами интеграции с «1С:Бухгалтерией».

Можно просто сказать, что заменив «1С:Бухгалтерию» на «1С:Управление производственным предприятием» или «1С:ERP Управление предприятием 2» вы получите не качественное, а количественное усложнение, которое связано с большим объемом настроек.

В условиях неустойчивой ситуации на рынках сбыта, вызванной кризисом собственник группы компаний хочет:

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

Это пожелания, можно сказать, «верхнего уровня», данные в терминах актуальных для собственника, финансовый департамент УК перевел в формализованные требования, которые выглядят следующим образом:

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

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

Данное решение имеет следующее обоснование:

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

Со стороны УК ГК на проект назначены:

• Куратор проекта в лице финансового директора группы компаний.
• Руководитель проекта в лице руководителя отдела ИТ.
• Спонсором проекта является владелец бизнеса, который планирует принимать активное участие в работе над проектом и заинтересован в «быстрых» практических результатах проекта.

По условиям примера финансовый департамент группы компаний выставил исполнителю следующие функциональные требования к программе (далее, для краткости, ФТ):

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

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

• Я предлагаю следующую схему функциональных блоков, определяющую их состав и порядок их автоматизации:

• Централизованное управление закупками (ФТ 2, ФТ 4)
• Организация процесса внесения и согласования договоров поставщиков дочерних предприятий ГК.
• Организация процесса создания и согласования заявок на закупку дочерних предприятий ГК.
• Организация процесса консолидации заявок на закупку в закупочные лоты.
• Электронные торги.
• Организация единой казначейской службы ГК (ФТ 3, ФТ 4)
• Организация процесса внесения и согласования заявок на оплату закупок дочерних предприятий ГК.
• Организация процесса внесения и согласования договоров с кредитными организациями ГК.
• Внесение планов поступления денежных средств от кредитных организаций.
• Внесение планов погашения кредитных обязательств.
• Организация процесса внесения и согласования договоров с покупателями товаров и услуг дочерних предприятий ГК.
• Внесение планов поступления денежных средств от клиентов.
• Формирование платежного календаря ГК.
• Бюджетирование и контроль (ФТ 1, ФТ 2, ФТ 3)
• Разработка структуры операционных бюджетов ГК.
• Разработка структуры мастер-бюджетов ГК.
• Разработка процессов внесения, согласования и утверждения бюджетов.
• Объединение функций среднесрочного и долгосрочного планирования и контроля в закупках.
• Объединение функций среднесрочного и долгосрочного планирования и контроля в казначействе.
• Разработка механизмов получения фактических данных для организации план-фактного анализа результатов деятельности предприятий ГК.
• Аналитическая отчетность (ФТ 1-6)
• Разработка необходимого комплекта отчетов.
• Разработка правил получения данных для отчетов.
• Разработка регламента предоставления/рассылки отчетов заинтересованным лицам ГК.

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

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

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

Кроме объективных причин именно такого приоритета действий, существуют и причины субъективные:

• Потребность в контроле закупок понятна каждому и на уровне дочернего предприятия трудно будет высказать какие-то обоснованные возражения против этого.
• Набор объектов (справочников и документов), а также бизнес-процессы оформления заявок на закупку достаточно просты, поэтому такая автоматизация не будет требовать привлечения серьезных ресурсов и даст быстрый результат.
• Автоматизация процесса подачи заявок на закупку зачастую реально упрощает работу рядового сотрудника предприятий холдинга: он получает инструмент удобного ввода данных и надзора за судьбой своей заявки. Также сокращаются и становятся предсказуемыми сроки рассмотрения заявки. Аналогична и обратная ситуация для лиц принимающих решения – у них тоже появится удобный инструмент для систематизации данных и оперативного их рассмотрения. То есть, в случае разумной автоматизации, Вы вряд ли столкнетесь с жалобами на рост занятости со стороны работников предприятия.
• Эффект от решения данной задачи существенен – даже если вы не сможете сразу адекватно оценить необходимость тех или иных закупок, вы получите общую картину этих закупок, сможете её классифицировать и адресно разобраться в тех областях, где закупки кажутся вам сомнительными. Также у сотрудников холдинга появится ощущение надзора за происходящим, что позволит сразу исключить множество злоупотреблений.

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

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

Состав работ самого блока централизованного управления закупками следует этой же логике:

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

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

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

Таким образом, у нас получилась «дорожная» карта проекта автоматизации группы компаний и теперь я перейду к деталям её реализации средствами программы «1С:Управление холдингом».

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

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

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

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

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

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

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

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

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

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

Что требуется сделать:

• Внести значение констант (настроек) программы;
• Определить методику работы со справочниками, которые будут загружаться в базу данных «1С:Управление холдингом» из баз данных дочерних предприятий;
• Настроить интеграцию программ с другими информационными системами дочерних предприятий в части справочной информации;
• Заполнить/загрузить и синхронизировать общие справочники;
• Вернуться к специфическим настройкам подсистемы управления закупками.

Настройки программы находятся на закладке «Настройки (Управление Холдингом)».

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

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

Подходить к выбору функциональной валюты следует ответственно, правила выбора здесь следующие:

• Если предприятие ведет свою деятельность в РФ и большая часть закупок приходится на товары российского производства, то целесообразно использовать в качестве функциональной валюты рубль.
• Если предприятие имеет западных владельцев или закупки более чем на 50% зависят от курса какой-либо валюты (доллара, евро и т.д.), то стоит использовать эту валюту в качестве функциональной. Обоснование здесь простое: если вы закупаете импортные товары и материалы в условиях неустойчивого растущего курса валюты закупок, то сводя отчетность в рублях, вы можете получить рублевую прибыль, при валютных убытках – вырученных в рублях средств может не хватить на закупку следующей партии товара. Следовательно, мы должны оценивать прибыль и убытки предприятия в валюте закупок. В случае западных акционеров использование соответствующей функциональной валюты может быть просто требованием владельцев.

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

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

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

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

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

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

Для работы демонстрационного примера предлагаю установить следующие флаги:

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

А переключатель «Формировать движения по лимитирующим бюджетам» нужно установить в положение «При интерактивном проведении экземпляров отчетов».

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

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

Переходим на закладку «Централизованное управление закупками», здесь:

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

На закладке «Технологические» указываем префикс информационной базы – этот префикс позволит отделить те документы и справочники, которые были созданы в данной информационной базе «1С:Управление холдингом» от документов и справочников, загруженных из других программ.

На закладке «Управление НСИ» указываем, что используются механизмы управления НСИ. Это означает, что мы будем управлять мастер-данными в программе «1С:Управления холдингом», то есть мы будем контролировать полноту и правильность заполнения элементов справочников, отсутствие дубликатов информации, а также сможем управлять справочной информацией в подчиненных информационных системах.

Прочие настройки оставим пока как есть.

Закончив с настройками нужно начать заполнять справочники, которые будут использоваться в работе подсистемы централизованного управления закупками «1С:Управление холдингом».

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

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

То есть, у нас есть четыре информационные базы, в которых ведется учет:

• Три «1С:Бухгалтерии» - в дочерних предприятиях;
• «1С:Управление холдингом» - в управляющей компании.

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

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

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

Для разрешения таких ситуаций был разработан комплекс мероприятий, который называется управлением мастер-данными. Для иностранного программного обеспечения используется термин MDM (Master Data Management).

В чем состоит управление мастер-данными:

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

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

• Составляется таблица правил обмена справочниками в Excel вида:

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

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

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

Возвращаясь к «1С:Управление холдингом», здесь все необходимые механизмы для настройки обмена, синхронизации и управления изменениями уже есть.

В качестве примера разберем как в «1С:Управление холдингом» организовать работу со справочниками номенклатуры и контрагентов.

Начнем с контрагентов:

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

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

Теперь о номенклатуре:

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

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

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

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

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

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

Вы начинаете работать с тем, что уже есть.

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

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

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

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

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

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

Далее все новые записи будут вноситься только в базе УК с использованием документа «Заявка на изменение НСИ». Документ создается на основании соответствующей записи справочника (новой, измененной, помеченной на удаление), после проведения документа создается задача соответствующему ответственному сотруднику.

Чтобы было более понятно, опишу данный процесс в лицах:

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

Подсистема управления закупками «1С:Управление холдингом» работает со следующими справочниками (здесь приведены справочники, которые требуют предварительного заполнения перед запуском подсистемы управления закупками, остальные будут описаны в контексте работы с подсистемой):

• Организационные единицы.
• Подразделения.
• Склады.
• Контрагенты.
• Договоры контрагентов.
• Номенклатура.
• Товарные категории.
• Периоды.
• Проекты.
• Пользователи.
• Роли контактных лиц.

Так как «1С:Управление холдингом» построено на базе конфигурации «1С:Бухгалтерия», то большая часть справочников и их функционал в этих программах совпадают. Поэтому я остановлюсь только на отличиях.

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

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

Подразделения, кроме типового функционала «1С:Бухгалтерии», содержат в себе ссылку на ЦФО к которому они относятся. И это может быть не обязательно та организация, к которой данное подразделение относится юридически (где числятся работники данного подразделения). К примеру, вы можете создать управленческую организационную единицу и подразделения всех реальных организаций привязать к ней. Таким образом, вы зададите управленческую структуру вашего холдинга, минуя промежуточное звено реальных юр. лиц.

Склады дублируют функционал «1С:Бухгалтерии», в дополнение у склада может быть указан подчиненный/связанный справочник мест поставки. Это новый справочник «1С:Управления холдингом», он содержит в себе информацию о географических местах, куда может поставляться/откуда должен забираться товар. Например, у поставщика есть склад, на котором хранится товар, и оттуда он будет поставляться в случае закупок. Или мы определяем свой склад как место поставки для поставщика. После этого эти места поставок могут фигурировать как требования к организации поставок в документах подсистемы управления закупками.

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

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

Договоры контрагентов – справочник имеет функционал справочника «1С:Бухгалтерии», плюс существенный дополнительный функционал «1С:Управления холдингом».

Из важного для подсистемы управления закупками:

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

Справочник номенклатуры, в дополнение к функционалу «1С:Бухгалтерии», содержит следующие механизмы, которые будут использоваться в подсистеме управления закупками:

• Можно указать ссылку на товарную категорию (классификатор номенклатуры с целью группировать закупки холдинга).
• Можно указать коды ОКДП, ОКПД2, ОКВЭД2.

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

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

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

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

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

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

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

В справочнике уже есть три служебных сценария:

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

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

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

Мной был предложен следующий вариант планирования расходов предприятия:

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

Подобная структура реализована в «1С:Управление холдингом», но с использованием справочника сценариев, количество разных вариантов планов у вас не ограничено.

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

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

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

Справочник пользователей – это просто справочник пользователей программы.

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

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

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

Возможно два варианта работы «1С:Управления холдингом» с потребностями группы компаний в закупках:

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

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

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

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

В виде упрощенной модели этот вариант выглядит следующим образом:

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

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

Стандартный вариант управления закупками выглядит следующим образом:

В систему предварительно вносятся бюджеты закупок.

При необходимости закупить что-то инициатор закупки создает и заполняет в программе «1С:Управление холдингом» документ резервирования бюджета закупки.

Документ отправляется на согласование, согласно заданному ранее маршруту согласования.

Если документ согласован, он становится рабочим (утвержденным), если не согласован – документ возвращается инициатору.

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

Запускается обработка «Определение способа покрытия потребностей».

Здесь можно выбрать вариант обеспечения потребности:

• Выставить на торги.
• Купить у существующего аккредитованного поставщика.
• Переместить с другого склада (возможно склада другой организации ГК).
• Купить по упрощенной схеме по счету или за наличные деньги.

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

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

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

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

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

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

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

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

По условиям договора производится оформления заявок на оплату (документ заявка на операцию).

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

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

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

Есть еще несколько замечаний относительно двух документов подсистемы управления закупками (речь идет о документах «Заявка на потребность» и «Резервирование бюджетов закупок»).

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

Виды операций делятся на три основные групп:

• БДДС – операции планирования денежного потока,
• БДР – операции планирования доходов и расходов,
• Ресурсы – операции отражающие движения ресурсов предприятия (мы будем именно их использовать в закупках).

То есть у нас есть соответствующие группы видов операций внесения планов по трем лимитирующим бюджетам:

• Бюджет движения денежных средств
• Бюджет доходов и расходов
• Бюджет ресурсов (прогнозный баланс)

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

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

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

Для этого в программе «1С:Управление холдингом» используется механизм универсальных процессов.

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

На закладке «Процессы и согласование» программы нужно создать новый шаблон универсального процесса, в котором выбрать режим процесса «Маршрут согласования», а затем, в типе согласуемого объекта, нужно указать «Документ», далее в согласуемом объекте требуется указать «Заявка на операцию» (наша заявка на закупку). После этого необходимо сохранить и закрыть новый шаблон.

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

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

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

Блоки бывают следующих видов (в той части, которая касается подсистемы управления закупками):

• Согласование – перечисляется список лиц/ролей согласовывающих документ (этап будет завершен, когда все пользователи выполнят согласование).
• Условный переход – некое условие, которое определяет дальнейший маршрут процесса.
• Оповещение – этап, на котором программа автоматически генерирует сообщение пользователю (текст сообщения задается в виде шаблона, сообщение оповещение может отправляться нескольким пользователям одновременно).
• Утвержден – этап, на котором согласуемый документ становится утвержденным.
• Отклонен – согласуемый документ отклонен.
• Служебные блоки:
• Подпроцесс (здесь можно указать другой шаблон процесса, который будет исполняться вместо этого блока).
• Обработка – в данном блоке можно задать некую процедуру (на встроенном языке 1С), которая может модифицировать объект нужным образом в тот момент, когда процесс дойдет до этого этапа. Например, будут добавлены какие-то автоматические комментарии.
• Пауза – задается пауза в часах в исполнении процесса.
• Ожидание события – задается некое событие в системе: например ожидается пока лимит задолженности по договору не будет соблюден. Регламентные задания программы проверяют – произошло событие или нет, и если произошло, то процесс движется дальше.

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

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

• Добавим один этап «Согласование»,
• У добавленного этапа укажем в ответственных роль «Закупщик»,
• Следующим этапом добавим этап «Объект утвержден».
• Соединим этапы связями (кнопка в меню формы конструктора).

Смысл этой настройки прост – документ будет попадать на согласование пользователю, который назначен на роль закупщика по тому ЦФО (организационной единице) по которому выписан этот документ.

После того, как настройка шаблона процесса согласования завершена требуется привязать этот шаблон к самому документу. Это делается отдельной обработкой «Матрица полномочий».

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

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

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

Так как запуск подсистемы централизованного управления закупок первоначально возможен по упрощенной схеме, без предварительного формирования бюджета закупок, то имеет смысл начать описание документов данной подсистемы с документа «Заявка на потребность», который позволяет ввести в систему и согласовать запрос на приобретение материалов/товаров/услуг.
Реквизиты документа разбиты на две части – обязательные для заполнения и не обязательные:

Обязательные реквизиты:

• Вид операции «Ресурсы (Приход): Планирование закупок».
• Период закупок – период, когда планируется производить закупки.
• Период потребности – период, в котором товар должен быть готов к получению от поставщика.
• Склад – склад, на который должны поступить товарно-материальные ценности (далее ТМЦ), для услуг смысла не имеет, но также требует заполнения.
• Организация – организационная единица, от которой был/будет заключен договор, может не совпадать с ЦФО, который по факту является инициатором и потребителем закупки. Для целей формирования упр. отчетности требуется правильное заполнение ЦФО. В нашем примере ЦФО и организации совпадают.
• ЦФО – организационная единица, в интересах которой фактически производится закупка и в бюджете которой она будет отражена.
• Желаемая дата – дата, по которой определяется период расходования лимитов закупок (из соответствующего лимитирующего бюджета).
• Сумма и валюта – стоимость закупаемых ТМЦ/услуг и валюта закупки. Фактически вы можете указать сумму и валюту и не заполнять перечень закупаемых товаров и услуг. В этом случае сам перечень товаров можно будет указать в документе заказа поставщику, который будет введен на основании заявки или в авансовом отчете в случае выдачи денег под отчет. Также, если вы укажете только сумму заявки, то часть отчетов системы по контролю закупок будет недоступна.
• Период контроля, период в котором формируются движения по бюджетам ресурсов.

• Не обязательные для заполнения реквизиты:

• Приоритет – приоритет закупки, требуется для сортировки и отбора документов в списках, отчетах и обработках.
• Источник лимитов – документ «Резервирование бюджетов закупки», из резерва которого производится закупка по данной заявке. Данный реквизит заполняется в том случае, если вы уже работаете по стандартной схеме (есть бюджеты и вы их резервируете), а заявка на потребность требуется для того чтобы оформить закупку по упрощенной схеме (но из существующего резерва), минуя консолидацию закупок, выбор способа обеспечения потребности, торги и пр. Например, требуется срочная закупка по готовому счету.
• Основание обязательства – документ основания закупки: счет поставщика.
• Проект – проект в интересах (и из бюджета) которого осуществляется закупка.
• Аналитики бюджета – статья движения бюджета ресурсов, по которой будет проводиться планируемая закупка. Если у статьи есть аналитические раскрытия (субконто), то они тоже здесь заполняются. Данный реквизит документа представляет собой табличное поле и для одной заявки может быть задано неограниченное число статей так, чтобы итоговая сумма по статьям совпадала с суммой документа. Данная возможность полезна, например, если вы закупаете материалы одновременно в интересах вашей основной деятельности (производства) и на административно-хозяйственные цели и т.д.
• Номенклатура заказа – перечень ТМЦ и услуг, которые вы планируете закупить. Если вы на стадии заявки точно не определили нужный вам номенклатурный артикул, то можно вместо номенклатуры указать товарную категорию. Цена номенклатуры указывается или вручную или может быть заполнена из типа цен «Тип цен для расценок заявки на потребность». Заполнение перечня номенклатуры в заявке позволяет автоматизировать заполнение документа заказа поставщику, а также более точно (детально) контролировать закупки, с точки зрения полноты и достоверности обеспечения потребностей в конкретной номенклатуре.
• Комментарий к документу заявки. Текстовый комментарий пользователя.

К этому описанию реквизитов документа требуется дать несколько рекомендаций/пояснений, которые позволят более уверенно работать в программе:

Назначение периодов и дат – в документе есть четыре реквизита, которые связаны со временем:

• Период закупки.
• Период потребности.
• Период контроля.
• Желаемая дата.

При их заполнении требуется соблюсти определенные правила:

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

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

Желаемая дата – конкретная дата, когда хотелось бы произвести закупку.

На этом описание документа завершено и можно привести несколько практических вариантов его применения:

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

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

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

Обязательные реквизиты документа:

• Вид операции «Ресурсы (Приход): Планирование закупок».
• Сценарий закупок – сценарий, по которому заданы лимиты закупок на период, из которых будет производиться резервирование (по умолчанию сценарий «План для лимитов»).
• Период закупок – период, когда планируется производить закупки.
• ЦФО – организационная единица, в интересах которой фактически производится закупка, может отличаться от организации, фактически фигурирующей в документах закупки.
• Сумма и валюта – стоимость закупаемых ТМЦ/услуг и валюта закупки.

Не обязательные для заполнения реквизиты:

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

При проведении документа формируетcя потребность в номенклатуре для объединения в единый план закупок группы компаний (консолидированный план потребностей).

Несколько примеров использования документа на практике:

• Ваше предприятие планирует привлечь подрядчика на выполнения разовых работ существенной стоимости и вам требуется организовать торговый конкурс на электронной площадке.
• У вас есть установленные лимиты на закупку, вы хотите контролировать их исполнение (не превышение).
• Несколько дочерних предприятий закупают ТМЦ из одной товарной группы, вы хотите получить скидку от поставщика за объем закупки.

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

Документ «Консолидированный план потребностей» объединяет в себя перечень товаров и услуг, которые были заявлены дочерними предприятиями группы компаний на определенный период закупок.

Заполнение документа:

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

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

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

Примеры использования документа:

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

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

• «План-фактный анализ закупок».
• «Потребность в номенклатуре».
• «Анализ бюджета движения ресурсов».

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

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

Для этих целей в программе «1С:Управление холдингом» используется обработка «Определение способов покрытия потребностей».
В обработке для отбора потребностей нужно указать период закупок.

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

Способов покрытия существует пять:

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

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

В процессе закрепления потребуется:

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

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

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

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

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

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

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

Этот процесс окончательной проработки лота состоит в следующем:

• Вам нужно указать способ выбора поставщика (запрос котировок, аукцион, конкурс и т.д.).
• Указать детали закупки (закрытая закупка из списка поставщиков, закупка в электронной форме, закупка по ФЗ-223).
• Указать начальную максимальную цену торгов (или заполнить её из типа цен «Начальная (максимальная) цена лота»).
• Указать место поставки (куда должен быть поставлен товар или где он может быть забран).
• Указать предмет договора, общие требования к поставщику/поставке, условия поставки, график исполнения, коды деятельности и пр.
• Даты начала подготовки закупок, официального объявления начала торгов, исполнения обязанностей по заключенному договору и т.д.

После этого лот может быть отправлен на согласование заинтересованным лицам.

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

Дальнейшую судьбу лота определяет вид организации, которая будет выступать в качестве организатора закупки. Если это коммерческая организация, то здесь следует руководствоваться внутрикорпоративными регламентами закупок, если же это организация, попадающая под действие ФЗ-223, то лот должен быть включен в годовой план закупок и размещен в ЕИС (на сайте www.zakupki.gov.ru).

Так как внутрикорпоративные регламенты разных коммерческих предприятий и холдингов могут значительно отличаться друг от друга, то в «1С:Управление холдингом» могут отсутствовать некоторые специфичные механизмы организации торгов, которые есть на вашем предприятии.

С другой стороны, требования ФЗ-223 достаточно однозначны и хорошо отработаны.

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

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

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

Этот список действий требует некоторых пояснений:

Для торгов, которые производятся через электронные торговые площадки (далее ЭТП) пункты 4-6 можно пропустить, так как торги производятся вне программы «1С:Управление холдингом» и по их завершению в программу загружается готовый протокол выбора победителя.

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

Для выбора победителя в случае офлайн-торгов используется обработка «Оценка альтернатив», которая достаточно интересна и требует более детального описания.

Для начала я хотел бы привести конкретный пример регламента выбора поставщика по контракту из моего опыта:

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

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

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

• Цена,
• Срок отсрочки,
• Условия поставки.

Я привел простые критерии, а могут быть и сложные – марка материала, производитель и пр. Разбор поступивших предложений в таких условиях достаточно трудоемок. Как итог, предложения выбирались или «на авторитете» (когда кто-то «продавливал» свой вариант) или выбор затягивался, что затрудняло работу предприятия.

В «1С:Управление холдингом» данная проблема решается достаточно просто и надежно:

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

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

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

Отчеты, которые помогут вам в работе с данными на этом этапе:

• «Потребность в номенклатуре».
• «Анализ бюджета движения ресурсов».
• «Годовая программа закупок».
• «План-фактный анализ закупок».
• «Анализ заказов поставщикам».
• «Отчет по заключенным договорам по итогам осуществленных закупок».

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


У вас могут остаться некоторые вопросы, на которые я постараюсь ответить:

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

• Как согласовать договор? Аналогично п.1, за исключением, возможно, другого маршрута согласования.

• Что такое программа закупок? Программа закупок – это регламентный документ, которым должны руководствоваться предприятия, работающие по ФЗ-223. В рамках данного закона предприятия должны формировать план закупок на год и выкладывать его в ЕИС (в программе этот документ называется программой закупок). Если вы – коммерческое предприятие, можете опустить этот функционал, тем более что он реализован в программе как простой отчет с преднастроенной согласно ФЗ-223 формой и не является обязательным.

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

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

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

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

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

Отчеты:

• «План-фактный анализ закупок».
• «Анализ заказов поставщикам».

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

Для таких случаев в «1С:Управление холдингом» предусмотрено два варианта работы:

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

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

Далее согласовать документ и на его основании создать документ заказа поставщику/выдать деньги под отчет.

Отчеты:

• «План-фактный анализ закупок».
• «Анализ заказов поставщикам».

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

В программе на этот случай есть соответствующий функционал.

Вы можете настроить обмен данными между «1С:Управление холдингом» и учетными программами дочерних предприятий и выгружать документы движения товарно-материальных ценностей и получать в программе актуальные остатки на складах.

Этот вариант достаточно интересен с точки зрения анализа направлений и статистики поступления и расхода ТМЦ, но он имеет существенные недостатки:

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

Для того, чтобы обойти эти сложности в программе предусмотрен механизм ввода остатков ТМЦ предприятий холдинга.
Этот механизм не предполагает переноса документов движений ТМЦ, а лишь регистрирует на определенный момент текущие остатки конкретного предприятия. Ввод остатков производится документом «Регистрация остатков ДЗО», остатки регистрируются один раз в день. Такой актуальности данных вполне достаточно для того, чтобы оценить существующие запасы на складах предприятий холдинга и принять решение об их использовании.

Кроме количественной оценки возможна стоимостная оценка складских запасов предприятий. При регистрации остатков указывается цена единицы ТМЦ.

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

Возможная схема работы с этими документами имеет следующий вид:

• Вы ведете управление закупками в программе «1С:Управление холдингом».
• Планирование закупок заканчивается вводом документа «Заказ поставщику».
• Фактический учет поступлений ТМЦ на склад производится в учетной программе конкретного дочернего предприятия.
• Вы переносите остатки раз в сутки из учетных программ дочерних предприятий холдинга в «1С:Управление холдингом» с помощью документа «Регистрация остатков ДЗО»,
• У вас есть актуальные остатки ТМЦ на складах в программе «1С:Управление холдингом» и вы можете принимать решение, что нужно закупать, а что можно получить, переместив товар между складами ГК.

Плюсы схемы:

• Простота настройки.
• Быстрый результат, позволяющий контролировать и управлять складскими запасами предприятий холдинга.

Минусы:

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

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

К такому подходу может возникнуть ряд «перспективных» вопросов и самый главный из них: Как анализировать направления расходования ТМЦ? Об этом рассказано в разделе, касающемся настройки и использования аналитических отчетов программы. Вкратце, ничто не мешает настроить загрузку движений ТМЦ не в виде первичных документов, а свернуто, по статьям бюджетов и получать информацию с той детализацией, которая необходима в отчетах (вплоть до ссылок на первичные документы).

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

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

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

Что у нас есть, если мы задействовали подсистему централизованного управления закупками:

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

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

Для оценки полученных результатов – посмотрите, что у вас сейчас есть на предприятии в части управления закупками и как это работает, и сравните с тем что возможно сделать, используя «1С:Управление холдингом».

Функционал «1С:Управление холдингом», предназначенный для планирования и учета движения денежных средств группы компаний, достаточно разнообразен. Можно сказать, что эта подсистема программы проработана в такой степени, что вы можете работать с ней изолированно, не используя другие механизмы программы.

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

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

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

К этой схеме требуются пояснения:

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

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

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

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

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

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

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

Ввод начальных остатков денежных средств производится документом «Корректировка начальных остатков», в дальнейшем актуальность данных поддерживается загрузкой документов банковских выписок из банк-клиента, а также оформлением (загрузкой) расходных и приходных кассовых ордеров в программу «1С:Управление холдингом» из баз данных учетных систем дочерних предприятий. Интеграция с банк-клиентом является типовым механизмом программы, настройка загрузки кассовых документов труда не составляет – набор их реквизитов достаточно стандартен.

Отчет, который позволит оперативно контролировать состояние источников платежей - «Ведомость по денежным средствам».

Общая схема документооборота для планирования расхода денежных средств имеет следующий вид:

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

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

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

Заполнение документа счета в «1С:Управление холдингом» не представляется сложным и является операцией аналогичной вводу счета в программах «1С:Бухгалтерия», «1С:Управление торговлей» и т.д. Вы вносите реквизиты поставщика, вносите перечень поставляемой номенклатуры, её количество, цену.

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

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

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

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

Отчеты по существующим счетам в программе не предусмотрены.

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

В этом случае, основанием для ввода заявки на оплату (заявки на операцию) становится сам договор.

Справочник договоров в «1С:Управление холдингом» имеет следующий функционал, относящийся к казначейской подсистеме.

Для договора можно указать способ формирования платежей:

• Вручную;
• График платежей;
• Процесс.

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

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

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

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

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

Этот процесс будет вызываться той же командой «Сформировать заявки».

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

Вы настраиваете процесс на год (или на время действия всего договора) и программа сама создает нужные заявки на оплату.

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

Теперь эту работу можно вести в программе. Договору можно установить признак «Договор финансового инструмента» и задать для него настройки периодических операций, которые будут содержать перечень платежей, предусмотренных по договору. Расчет платежей ведется в автоматическом режиме. При расчетах могут использоваться такие параметры, как остаток основного долга, выбранный лимит и так далее.

Для ввода таких заявок на оплату необходимо воспользоваться самим документом «Заявка на операцию», в котором указать соответствующий вид операции.

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

Для планирования поступления денежных средств будет использоваться тот же документ «Заявка на операцию».
При планировании поступления денежных средств используются виды операций находящиеся в группе «БДДС (Приход)».

Рассмотрим работу с этим документом на примере ввода плана оплаты клиента.

• У одного из дочерних предприятий холдинга есть клиент ООО «ОптТорг», этот клиент приобрел продукцию предприятия и по условиям договора должен её оплатить в течение 30 дней.
• Для отражения этой перспективной оплаты требуется создать документ «Заявка на операцию» с видом операции «БДДС (Приход) расчеты с контрагентами».
• В документе заявки требуется указать сумму ожидающейся оплаты, дату планового поступления, контрагента, договор, организацию, ЦФО.
• Требуется провести и закрыть документ.

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

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

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


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

• Как поступить в ситуации, если у нас небольшие по объему продажи, но их много – оплату по каждой не запланируешь вручную? Есть два варианта: загружать в «1С:Управление холдингом» документы автоматически, на основании первичных документов отгрузки и сроков отсрочки или вводить информацию о плане поступления денежных средств не документом «Заявка на операцию», а документом «Экземпляр отчета». Второй вариант позволяет внести общую плановую сумму прихода денежных средств, исходя, например, из бюджета доходов. Этот вариант планирования описан в части руководства посвященной подсистеме бюджетирования программы.

• Как отразить поступление кредитов в программе? Этим же документом «Заявка на операцию». Вносите кредитный договор (договор финансового инструмента) и на его основании оформляйте заявку на операцию с видом операции «БДДС (Приход): расчеты по кредитам и займам с контрагентами», документ также можно создать в платежном календаре.

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

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

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

Предприятию жизненно важно знать:

1. Какими финансовыми ресурсами оно обладает.
2. Какие поступления денег запланированы.
3. Какие оплаты требуется произвести.

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

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

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

По каждой группировке этой иерархии выводится информация о:

• Начальных остатках денежных средств на текущую дату;
• План прихода/расхода денежных средств по дням на период краткосрочного планирования (задается константой программы);
• Свернутые данные по планируемым платежам и остаткам денежных средств вперед на неделю/месяц/квартал/год и т.д. (в зависимости от настройки отчета).

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

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

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

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

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

Платежный календарь предназначен для того, чтобы управлять денежными средствами с учетом определенной временной перспективы. Но, когда приходит конкретная дата, нужно окончательно утвердить перечень платежей, которые будут отправлены в банк на исполнение. Для этого используется документ программы «1С:Управление холдингом» «Реестр платежей».

Документ может быть создан из отчета «Платежный календарь» или из формы списка документа «Реестры платежей».

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

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

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

Данный функционал программы «1С:Управление холдингом» позволяет задать набор правил, которые будут блокировать/разрешать оплату.

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

Правила разрешения имеют более высокий приоритет, чем правила запрета.

Если нет правил запрета, то считается, что платежи разрешены по умолчанию.

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

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

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

В рамках поддержки законодательства о гособоронзаказе в программе «1С:Управление холдингом» предусмотрен следующий функционал:

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

Фактические данные о произведенных платежах, а также о том, какие платежи были получены от контрагентов на расчетный счет, загружаются вначале в клиент-банк, а из него в программу «1С:Управление холдингом».

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

Здесь используется обработка «Разнесение банковских выписок по аналитикам планирования».

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

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

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

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

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

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

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

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

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

Если ваше предприятие при автоматизации идет по плану, описываемому в руководстве, то на данном этапе вы получили следующее (вместе с результатами автоматизации закупок):

• Полностью контролируются закупки холдинга, начиная с намерения произвести закупку, заканчивая контролем производимых оплат. Доступны для анализа материальные запасы на складах группы компаний.
• Автоматизирована договорная работа в холдинге, начиная от согласования будущего договора и заканчивая контролем исполнения договорных обязательств.
• Имеются централизованные классификаторы контрагентов, банковских счетов, договоров, закупаемых товарных категорий. Данные доступны для проверки службой безопасности предприятия.
• Ведется оперативное планирование денежного потока, доступны данные об остатках денежных средств холдинга. Можно контролировать и предупреждать возникновение кассовых разрывов. Как следствие снижены потребности в срочных займах.
• Ведется работа с кредитными организациями, автоматизированы процессы получения займа, выплаты процентов по займу, погашения займа.
• Для предприятий, которые участвуют в выполнении гособоронзаказа, доступны удобные рабочие инструменты.
• Централизовано собирается информация о производимых закупках и оплатах (входящих и исходящих). Эти данные доступны для анализа и могут служить полноценной основой для построения системы среднесрочного/долгосрочного планирования в холдинге.

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

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

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

Для каждого из предприятий ГК задается комплект бюджетов:

• Бюджет (план) продаж;
• Плановая смета затрат;
• Бюджет доходов и расходов;
• Бюджет по балансовому листу (прогнозный баланс);
• Бюджет движения денежных средств.

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

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

Схема взаимодействия бюджетов выглядит следующим образом:

Состав самих бюджетов следующий:

Плановая рентабельность
Показателем бюджета является % рентабельности бизнеса.
Бюджет заполняется в управляющей компании вручную для каждого дочернего предприятия отдельно.
План продаж


Показателем бюджета является сумма в рублях.
Бюджет заполняется вручную на каждом дочернем предприятии.
Плановая смета затрат
Статьи
Выручка от продаж
Плановая рентабельность
Затраты в долях
Стоимость основных материалов
Заработная плата
Административно-хозяйственные расходы

Показателями бюджета являются доли затрат в процентах от выручки (выручка = 100%).

Бюджет заполняется полуавтоматически на каждом дочернем предприятии, при заполнении бюджета автоматически заполняется плановая рентабельность дочернего предприятия из бюджета «Плановая рентабельность».

Бюджет доходов и расходов


Валовые продажи
Стоимость основных материалов


Административно-хозяйственные расходы
Прибыль/Убыток

Показателями бюджета являются суммы в рублях.

Для дочерних предприятий бюджет заполняется автоматически на основании данных бюджетов «План продаж» и «Плановая смета затрат».

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

Прогнозный баланс (бюджет по балансовому листу)



Денежные средства на счетах и в кассах
Дебиторская задолженность
Кредиторская задолженность



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



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

Для дочерних предприятий бюджет заполняется на основании бюджетов «Бюджет доходов и расходов» и «Прогнозный баланс».
Для холдинга бюджет формируется на основании бюджетов дочерних предприятий, внутригрупповые обороты элиминируются.

План закупок
Статьи
Закупки товаров и услуг под основной вид деятельности
Показателями бюджета являются суммы в рублях.
Бюджет формируется на основании бюджета «План продаж» дочерних предприятий.
Лимиты закупок
Статьи
Административно-хозяйственные расходы
Закупки товаров и услуг под основной вид деятельности
Показателями бюджета являются суммы в рублях.

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

Лимиты оплат
Статьи
Заработная плата
Административно-хозяйственные расходы
Оплаты поставщикам

Показателями бюджета являются суммы в рублях.

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

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

У модели есть несколько интересных особенностей, на которых хотелось бы остановиться подробнее.

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

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

Это можно увидеть на примере:

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

А как эти цифры соотносятся с текущим долгом клиентов? Может быть ,у нас долгов на 20 млн., а нам нужно в течение года снизить эту цифру до 5% от объема продаж за месяц (выйти на цифру в 5 млн.). Или мы, наоборот, планируем расти и готовы увеличить срок отсрочки оплаты клиентам так чтобы выйти на плановые показатели дебиторской задолженности в 30% от объема продаж за месяц (увеличить дебиторку до 30 млн.).

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

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

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

Как в данной ситуации планировать наши возможные расходы?

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

С такой ситуацией я столкнулся, в группе компаний «Добрый Колбасник».

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

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

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

Но насколько правильным будет так углубляться в детали:

• Перечень выпускаемой продукции может меняться (на предприятии шла ежегодная ротация 30% артикулов);
• Состав рецептур тоже меняется;
• Цена материалов меняется.

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

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

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

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

Под бюджетом в программе «1С:Управление холдингом» подразумевается три объекта:

• Справочник видов отчетов;
• Справочник бланков отчетов;
• Справочник экземпляров отчетов.

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

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

Бланк отчета описывает внешний вид отчета. Разметка, положение колонок/строк на странице и т.д.

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

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

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

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

• Для сбора данных (планов или фактов) от дочерних предприятий холдинга лучше использовать статичные бланки. Речь сейчас идет о случаях, когда невозможно автоматически загрузить данные в программу и их вносят вручную. В программе есть возможность выгрузить такой бланк в формате Excel, заполнить его данными и загрузить обратно в программу.
• Для анализа бюджетных данных лучше пользоваться бланками сводных таблиц. Здесь можно динамически менять внешний вид бюджетного отчета по необходимости (группировать данные, менять порядок группировок, добавлять отборы и так далее).
• Также в сводных таблицах удобно работать с данными консолидированных бюджетов холдинга, анализируя ситуацию и внося нужные изменения.
• Статичные бланки можно использовать для подготовки итоговой отчетности для руководства и/или специалистов компании, если в холдинге есть определенные требования к внешнему виду отчетов.

При заполнении бюджетного отчета можно:

• Вносить плановые значения вручную.
• Рассчитывать значения ячеек на основании данных других ячеек этого отчета, задавая формулу (также как вы это делаете в Excel).
• Использовать при вводе данных одного бюджетного отчета данные другого отчета (при необходимости нескольких отчетов/с использованием формул). Например, мы заполнили бюджет продаж и плановую смету затрат и из этих отчетов по формулам автоматически получаем значения бюджета доходов и расходов.
• Использовать базу данных программы «1С:Управление холдингом» - получать данные для бюджетов из регистров, документов, справочников программы.
• Использовать внешние базы данных учетных программ 1С для заполнения бюджетов. Также в комбинации с формулами и другими отчетами. Например, дочернее предприятие ведет учет в программе «1С:Управление производственным предприятием», вы настраиваете правила расчета данных внешней базы, настраиваете источник получения данных (например, регистр бухгалтерии), настраиваете отборы получения данных и можете работать с этой информацией в отчетах (заполнять ячейки, использовать в формулах).
• Использовать произвольные запросы к базам данных учетных программ производства компании 1С. Можно создать любой запрос с выборкой любых данных и получать их сразу в бюджетных отчетах.
• Использовать интерфейс ADO для работы с базами данных программ любых других производителей.

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

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

Нужно:

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

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

«1С:Управление холдингом» позволяет автоматизировать процесс подготовки бюджетов. Для этого используются:

• Механизм управления отчетными периодами;
• Регламенты подготовки отчетности;
• Универсальные процессы;
• Матрица полномочий.

Использование этих инструментов лучше описать на примере:

Мы приняли решение, что нам требуется готовить планы на год один раз в год, начиная с 1 декабря и заканчивая 20 декабря. А лимиты закупок и оплат будут актуализироваться и вноситься на каждый месяц за 5 дней до его начала.

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

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

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


В нашем примере:

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

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

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

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

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

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

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

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

У данного сценария два назначения:

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

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

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

Лучше всего понять эту концепцию можно на таком примере:

• Мы создали набор нужных нам видов бюджетных отчетов (План продаж, БДР, БДДС, ББЛ и так далее);
• В программе, кроме предопределенных сценариев, заведен ещё один сценарий «Основной сценарий планирования»;
• По этому сценарию занесены данные наших планов (внесены вручную и/или рассчитаны автоматически);
• По итогам прошедших периодов мы вносим фактические данные о деятельности предприятия для тех же видов бюджетных отчетов по сценарию «Факт» (занесение фактических данных ведется вручную и/или информация заполняется автоматически на основании оперативного учета/бухгалтерии/загрузки данных из внешних источников и так далее);
• Мы создали бланки сводных таблиц для наших видов бюджетов, в которых можно сравнить информацию по разным сценариям – получить план-фактный анализ.

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

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

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

В программе «1С:Управление холдингом» можно решить эту проблему двумя способами:

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

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

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

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

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

В программе есть три предопределенных сценария бюджетирования:

• План для лимитов;
• Резерв;
• Факт.

Сценарий «Факт» используется для отражения фактических данных. А вот два других сценария служат для лимитирования планируемых операций.

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

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

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

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

У нас есть три специальных встроенных вида бюджетов (не путать с видами отчетов):

• Бюджет доходов и расходов;
• Бюджет движения денежных средств;
• Бюджет движения ресурсов.

Все эти бюджеты оборотные и используются для планирования и контроля операций в системе «1С:Управление холдингом». То есть именно по ним проводится проверка – можно ли оформить заявку на операцию или резерв бюджета.

Эти виды бюджетов имеют специализированные классификаторы операций:

• Справочник статей доходов и расходов;
• Справочник статей движения денежных средств;
• Справочник статей движения ресурсов.

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

Достаточно сложная концепция, которая требует практического объяснения.

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

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

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

Я сделал так сознательно, чтобы избежать на начальном этапе проблем, связанных с формированием адекватных планов/лимитов и вызванных этим задержек в закупках и оплатах.

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

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

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

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

Этот инструмент показывает для заданной ячейки отчета её значение из других сценариев планирования/периодов планирования. Здесь можно проводить сравнительный анализ данных разных сценариев, план-фактный анализ деятельности предприятия.

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

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

Инструмент доступен в бланках отчетов в меню «Дополнительно».

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

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

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

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

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

Таким образом, мы достигли основных целей, которые были заявлены заказчиком, когда он принял решение о том чтобы использовать «1С:Управление холдингом» в качестве системы управления своей группой компаний.

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

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

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

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

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

В «1С:Управление холдингом» таким инструментом являются аналитические отчеты.

Аналитический отчет представляет собой комбинацию:

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

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

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

Настройка источников данных схожа с настройкой правил расчета бюджетных отчетов. Здесь используется один и тот же функционал программы «1С:Управление холдингом».

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

Визуальные представления могут быть трех видов:

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

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

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

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

Как это выглядит на практике: например, вы хотите получить комплексные данные о состоянии продаж:

• Текущий объем продаж с начала месяца;
• Текущая дебиторская задолженность;
• Процент возвратов проданной продукции;
• Средняя стоимость одной сделки.

Вы создаете в программе «1С:Управление холдингом» новый аналитический отчет, вида «Мониторинг аналитических показателей» и создаете в нем нужные вам строки ключевых показателей.

При настройке одного показателя требуется указать или создать три источника данных (аналогично тому, как это делается в аналитических отчетах вида «Таблица или диаграмма»):

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

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

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

Более того, показатели отчетов могут быть сгруппированы по областям анализа и их можно привязать к стратегическим целям развития предприятия. С помощью этого в программе «1С:Управление холдингом» реализована методика управления с использованием системы сбалансированных показателей (BSC). Показатели будут являться аналогом KPI, аналитические отчеты с видом «Монитор ключевых показателей» представлять собой карты показателей по ответственным, а стратегия развития предприятия будет «кодифицирована» в областях анализа и стратегических целях.

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

В группе компаний «Добрый Колбасник» было принято решение использовать в работе следующую систему мотивации:

Зарплата каждого руководителя отдела состояла из трех частей:

• 40% - постоянная часть,
• 30% - выполнение заданных планов (KPI),
• 30% - выполнение SMART задач.

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

Состав KPI отдела был достаточно стабилен, могли происходить только изменения в конкретных значениях показателя в зависимости от стратегии развития, сезона и инфляции.

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

Такой «двухкомпонентный» подход в мотивации встречается достаточно часто – фиксированная часть и премия по результатам работ. Но у нас была ещё и третья переменная часть – SMART задачи, о них я расскажу подробнее.

Термин «SMART задача» является устоявшимся понятием в области менеджмента. Он означает задачу, которая ставится перед исполнителем на определенный период, задача должна иметь конкретный достижимый результат, который можно измерить; задача должна быть понятна исполнителю и адекватна его возможностям.

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

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

Возвращаясь к функционалу программы «1С:Управление холдингом». В качестве инструмента для реализации механизмов KPI в программе используются мониторы ключевых показателей. А для SMART задач предназначен справочник инициатив.

Элемент этого справочник может содержать следующую информацию:

• Наименование инициативы (задачи);
• Ответственное лицо за инициативу (задачу);
• Дата начала-дата окончания задачи;
• Процент выполнения задачи;
• Затраты по задаче (план/факт);
• Участники задачи.

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

Расширением функционала монитора ключевых показателей можно считать механизм аналитических панелей.

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

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

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

В дополнение к выводу на экран, аналитические панели могут рассылаться по электронной почте. Для этого используется механизм аналитических рассылок программы «1С:Управление холдингом».

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

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

На этом я хочу завершить описание функционала программы «1С:Управлние холдингом».

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

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

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

Компания Раздолье-Консалт, под чьим патронажем готовилось это руководство, сотрудники которого активно участвовали в его создании, готова выполнить для вас проект автоматизации вашего предприятия, как с использованием этой программы, так и на базе программ «1С:ERP Управление предприятием 2», «1С:Комплексная автоматизация 2». Я сам являюсь руководителем проектов этой компании и, вполне возможно, буду работать над вашим проектом.

В качестве завершающей части хотелось бы сказать следующее:

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

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

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

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

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

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

В завершение, хотелось бы напомнить, что компания «Раздолье-Консалт» планирует и дальше рассказывать о возможностях новых программ производства компании «1С» («1С:ERP Управление предприятием 2», «1С:Управление холдингом 8»). Это будут как функциональные (производство, логистика и т.п.), так и отраслевые учебные материалы. Мы будем рады получить ваши замечания и предложения на почту edu@razdolie.ru.

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

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

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

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

Принимая во внимание такой подход, стоит учитывать что:

• Автоматизация, постановка учета и планирования будут требовать не только развертывания и применения какого-то специфичного программного продукта, но и многих организационных шагов.
• Процесс, скорее всего, будет многоэтапным, а возможно и итерационным. Когда на первом этапе вы, например, организуете централизованный процесс подачи заявок на закупку, а на втором этапе привязываете заявки на закупку к оплатам и получаете централизованное казначейство. А потом вы можете вернуться опять к закупкам и перейти на проектный подход в закупках, когда те или иные заявки привязываются к определенным выполняемым предприятием проектам и расходы и денежный поток определяется не целиком по предприятию, а в разрезе каждого проекта. Определяя практические результаты проекта внедрения «1С:Управление холдингом», вы должны осознавать, что не все можно сделать сразу и «на отлично». Иногда стоит выбрать дальнюю дорогу поэтапного внедрения и удовольствоваться умеренным промежуточным результатом, для того что предприятие как можно быстрее получило практическую отдачу от внедряемой системы.

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

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

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

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

• Откровенно обозначить для всех участников работ цели проекта автоматизации внутрихолдингового учета, какими они видятся УК и собственникам: «МЫ хотим понять – куда тратятся деньги», «МЫ хотим сократить необоснованные траты» и т.д. То есть все попытки «подсластить пилюлю» тем что «мы это делаем для ВАС, наши ЛЮБИМЫЕ сотрудник дочерних предприятий» - это плохой подход. Все участники проекта (руководители и работники дочерних предприятий) компетентные специалисты и прекрасно понимают что и для чего делается. Цели вышестоящего субъекта, по контролю их деятельности они прекрасно понимают и готовы с ними смириться, а вот попытку навязчиво «улучшить жизнь» со стороны воспримут чаще всего негативно. Такой откровенный подход к автоматизации решит проблемы с конфликтом интересов между УК и дочерними предприятиями: все будут понимать что происходит и какая реальная цель у проекта.

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

Если детализация вас не устраивает, привлеките людей в УК для дополнительно проработки поступающих с дочерних предприятий данных. Это позволит решить проблему с увеличением объемов работ в «дочках» и позволит получить результаты быстрее. В теории, как управляющая компания, вы можете ЗАСТАВИТЬ дочерние предприятия выполнять работу так, как нужно вам. Но на практике вы, скорее всего, получите недостоверную и несвоевременную информацию и работу сотрудников дочерних предприятий спустя рукава (под лозунгом того, что «уже есть своя работа, которую не отменяли») и в итоге потребуется всё равно привлечь собственные ресурсы УК чтобы выправить эту ситуацию – не лучше ли сразу рассмотреть этот вариант? По мере привыкания к новым реалиям, а также по мере оптимизации рабочих процессов работу можно передать на места.

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

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

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

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

Проект автоматизации крупных предприятий – это достаточно сложный многоэтапный процесс, некоторые шаги, которого не всегда понятны заказчику. Я хотел бы привести примерный разбор такого проекта, как если бы речь шла о внедрении «1С:Управление холдингом», на нашей абстрактной группе компаний.

Этапы проекта следующие:

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

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

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

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

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


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

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

• Уход в ненужные детали: этап функционального моделирования все-таки ограничен по времени, поэтому все варианты тех или иных операций зачастую увидеть не возможно. Что это значит на практике: например, есть в программе документ реализации товаров и услуг. В целом это понятная операция, но могут быть отдельные контрагенты, у которых может быть какой-то «хитрый» договор поставки или сложный график оплаты или очень сложная система скидок. Если мы будем перебирать все маргинальные варианты реализаций на этапе функционального моделирования, то на остальное времени может и не хватить или функциональная модель будет иметь «дыры» в своей структуре или потребуется дополнительное финансирование для продолжения моделирования. А если еще предположить, что в процессе моделирования у заказчика что-то меняется, появляются новые варианты учета, которые также детально описываются – работа может стать неисполнимой. Избежать этой ошибки достаточно просто: если в функциональной модели охвачено 80% учетных операций, то этого достаточно. Если вдруг в процессе опытной эксплуатации будет обнаружено, что часть функционала программы требует доработки под какие-то особые случаи учета, то производится актуализация функциональной модели, пишется техническое задание на доработку и программа дорабатывается. Это делается из бюджета этапа опытной эксплуатации, но в любом случае эти деньги пришлось бы потратить – или на этапе доработок или на этапе опытной эксплуатации. В целом для этапа функционального моделирования требуется разумный подход в детализации модели, при условии быстрого получения нужного результата: если вы, как заказчик, видите, что то, что вам предлагается, может быть полезно предприятию – это нужно быстрее запустить в работу.

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

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

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

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

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

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

Из второстепенного, но тоже важного:

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

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

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

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