Финансы - справочники. Внедряем ERP на промышленном предприятий - шаг 4.

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

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

Предыдущая статья: Отступление 1. Без неё ERP на предприятии не внедрить

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

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

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

Каковы цели?

• Закрепляем справочники за подразделениями.
• Получение из ERP всех необходимых финансовых документов в рамках исполнения договоров.
• Обработка банковской выписки в системе.
• Контроль остатков на расчетных счетах.
• Контроль финансового исполнения договоров.

Что имеем?

В ERP из PLM:

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

В ERP:

• центральные склады МКИ;
• склады СГП.
• электронный документ ТОРГ-12 или УПД (Универсальный передаточный документ).

На предприятии:

• отдел продаж;
• отдел закупок;
• отдел финансов;
• подразделения договородержатели
• установленное в отделе финансов ПО банков – клиент-банк свой для каждого банка, с которым работает предприятие.

Что делаем?

Закрепляем справочники за подразделениями.



Для выставления или обработки финансовых документов в ERP нужна следующая информация о:

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

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

ВАЖНО. Владелец объекта в ERP – лицо или служба, ответственная за ведение и контроль информации в данном объекте.

ВАЖНО. Ведение информации – добавление, изменение, удаление информации в объект ERP.

ВАЖНО. Контроль информации – соблюдение бизнес-правил определенных для объекта в ERP.

ВАЖНО. Владелец информации – лицо или служба, обладающая максимально достоверной информацией по какому-либо объекту в ERP.

Для закрепления работы со справочниками идеальным вариантом является назначение владельцем объекта ERP владельца информации. К этой идеальной модели надо стремиться на всех этапах внедрения и по всем объектам ERP.

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

• убираются лишние звенья между ERP и владельцем информации;
• ведение и контроль за информацией осуществляет её владелец.

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

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

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

Завести в справочник Партнеров ERP Партнера должна служба, назначенная приказом по предприятию Владельцем объекта ERP «Справочник Партнеров».

ВАЖНО. Идеальным вариантом является ситуация, когда за один объект в ERP отвечает только одна служба. Но бывают и необходимые исключения.

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

• отдел продаж – договорами продаж основной продукции предприятия;
• отдел закупок – закупками плановой номенклатуры материалов и комплектующих, РЭН и ещё ряда направлений;
• ИТ отдел – договорами по ИТ направлению;
• строительное подразделение – договорами на строительство и обслуживание;
• отдел оборудования – договорами на приобретение, монтаж и поддержку оборудования;
• и т.д.

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

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

Однако запись о Партнере в ERP должна быть только одна.

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

Почему?

ВАЖНО. Справочник – особый объект ERP, он может и должен содержать только одну запись об отдельном элементе справочника, в нашем случае Партнере.

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

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

В связи с этим, ни одно подразделение предприятие, как правило, не желает:

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

Какие варианты решения вопроса применяются на практике на разных предприятиях:

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

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

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

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

• продажам – отдел продаж;
• закупкам – отдел закупок.

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

• первые внутренние номера ERP для записей покупателей продукции предприятия, начинающиеся, ну скажем с 0 до 20 млн., а для покупателей продавцов – с 40 млн. до 60 млн.;
• признак «Доступен для продаж», который ставится по умолчанию для записей, которые заводятся в диапазоне внутренних номеров от 0 до 20 млн., и признак «Доступен для закупок», присутствующий по умолчанию для записей в диапазоне внутренних номеров от 40 до 60 млн.;
• признаки «Доступен для продаж» и «Доступен для закупок», при заведении партнера с внутренним номером не их диапазона, имеют признак – не выбраны.

Когда, например, сотрудник отдела продаж, получает новую заявку от потенциального покупателя и желает завести её в справочник Партнеров, он вводит в справочнике ИНН и получает:

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

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

• по партнерам покупателям продукции и услуг предприятия – агрегатором становится отдел продаж;
• по партнерам поставщикам продукции и услуг предприятию, агрегатором становится отдел закупок.

Для служб предприятия это означает, что если любая служба:

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

Забегая чуть вперед, отмечу, что информацию о договоре в ERP будет заводить сама служба владелец договора.

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

• «Партнеры» - отдел продаж и отдел закупок;
• «Банки» - отдел финансов;
• «Расчетные счета» - отдел финансов;
• «Условия оплаты» - отдел продаж и отдел закупок.

Результат подпункта.

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

Следующая статья: Финансы: основные реквизиты договоров. ERP на предприятии - шаг 4.1.

Автор: Андрей Лабутин