1С:Управление Холдингом 8, часть 2: Организация процесса закупок в холдинге (настройка системы и управление мастер-данными)

Предварительные замечания

Продолжение курса по 1С:Управление Холдингом, 1 часть находится по ссылке: //infostart.ru/public/564686/

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

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

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

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

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

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

Настройки и ввод справочной информации

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Видео, в котором показаны производимые настройки системы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вернемся к программе: настройки механизмов управления мастер-данными находятся на закладке «Интеграция и управление НСИ».

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

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

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

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

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

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

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