Оптимизация бизнес-процессов управления денежными потоками финансового отдела

1. Настройка подсистемы 1С Казначейство

2. Создание Заявки на расходование денежных средств

3. Связь с системой лимитирования

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

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

Заявки на расходование денежных средств можно сформировать как в ручном режиме, так и на основании иных документов в системе.

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

1. Настройка подсистемы 1С Казначейство

Настройка подсистемы 1С Казначейство выполняется в форме Настройки Казначейство и взаиморасчеты раздела НСИ и администрирование.

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

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

2. Создание Заявки на расходование денежных средств

Журнал Заявок на расходование денежных средств находится в разделе «Казначейство – Планирование и Контроль денежных средств – Заявки
на расходование ДС».

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

· Выдача денежных средств подотчетному лицу;

· Перечисление денежных средств поставщикам;

· Перечисление налогов и взносов;

· Таможенный платеж;

· Оплата другой организации;

· Оплату лизингодателю;

· Остальные расходы денежных средств.

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

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

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

Заполняемые поля:

· Организация

· Подразделение

· Дата платежа

В поле «Сумма» необходимо указать сумму к оплате.

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

Руководство компании сможет решить, как распределить деньги по нескольким Банковским счетам или Кассам. Для этого следует перейти на закладку «Распределение по счетам».

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

Нажимая кнопку «Провести и закрыть», завершаем регистрацию Заявки.

Формируя заявки на расходование ДС, система помогает решить следующие задачи и цели:

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

· спланировать расходы денежных средств, оформить платежный календарь в 1С;

· контролировать несогласованные выплаты денежных средств;

· проконтролировать величину свободных денежных средств.

Заявка на расходование ДС контролируется при помощи статусов документа.

Статусы заявок:

· Не согласована – Заявка формируется.

· Согласована – Заявка включена в план платежей.

· К оплате – разрешено оформление платежных документов на основании Заявки.

· Отклонена – руководство компании не согласилось с заявленным платежом.

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

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

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

3. Связь с системой лимитирования

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

В разделе «НСИ и администрирование – Казначейство и взаиморасчеты».

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

Лимиты контролируются в разрезе Статей ДДС. Кроме того, пользователь также может установить в настройках дополнительные разрезы контроля – Подразделение и Организацию.

При превышении лимита (либо его отсутствии) программа не даст провести Заявку:

Если необходимо создать заявку сверх бюджета по лимиту, устанавливаем флажок «Сверх лимита».

Лимиты в систему вводятся в разделе Казначейство:

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

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

Специалист компании ООО «Кодерлайн»

Илона Матей.

ЦЕЛЬ

Описание бизнес-процессов по принятию и исполнению Заявок на оплату в финансовом отделе необходимо для контроля. Контроль — это общее слово, поэтому его нужно конкретизировать, указать более узкие функции:

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

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

РАБОЧАЯ ГРУППА

Формирование рабочей группы — первый важный шаг в описании и оптимизации бизнес-процессов.

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

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

ОБРАТИТЕ ВНИМАНИЕ

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

  • Аналитики проекта — собирают информацию, формируют модели, разрабатывают регламенты. Хорошими Аналитиками покажут себя сотрудники, которые в своей деятельности так или иначе сталкиваются с анализом или регламентацией деятельности компании. Как правило, это специалисты отделов планирования и анализа. Поскольку речь идет об описании бизнес-процесса в рамках одного отдела, то необходимо выбрать одного или двух сотрудников из финансового отдела. Если в штате отдела присутствует экономист, то лучше взять экономиста;
  • когда в проекте работает несколько Аналитиков, они параллельно описывают различные процессы, работают на разных подуровнях описания, поэтому нужен Интегратор. Интегратором рекомендуется брать одного из Аналитиков или Руководителя проекта. Его задача — обеспечить целостность бизнес-процесса, координацию работы Аналитиков, чтобы их модели не пересекались, были одинаково подробными;
  • если в качестве Аналитиков в рабочую группу не были включены непосредственные исполнители, то последних привлекают к работе в качестве Экспертов. Эксперты — это ключевые сотрудники, которые участвуют в бизнес-процессе. В данном случае экспертами будут бухгалтеры-операционисты, которые на основании Заявок на оплату формируют платежные поручения, контролируют их проведение по системе «Клиент-Банк». Главное правило: не берем в число экспертов новых сотрудников компании.

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

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

ЭТО ВАЖНО

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

ДЕРЕВО ПРОЦЕССОВ

Рабочая группа разрабатывает единое дерево бизнес-процессов финансового отдела (рис. 1).

Дерево бизнес-процессов — это все функции, которые выполняет подразделение или компания.

Название данного дерева бизнес-процессов — «Ф0. Функции Финансового отдела/Управление денежными потоками».

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

«0» — объединяющий уровень, поскольку дерево на рис. 1 описывает все аспекты работы финансового отдела компании.

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

При создании дерева бизнес-процессов оговаривается степень детализации (уровни). Рассмотрим пример детализации:

1. Бизнес-процессы верхнего уровня:

Ф1. Осуществление платежей;

Ф2. Составление Отчета о движении денежных средств;

Ф3. Составление Платежного календаря;

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

Ф1–Ф7 — это группы бизнес-процессов. Их столько, сколько функций обозначено в Положении об отделе (условно: группа бизнес-процесса = функции отдела).

Понятие группы не следует путать с понятием «уровень/степень детализации». Уровней, как правило, делают не больше пяти. Пример самого низкого уровня на рис. 1 — это «Ф1.2.1.1.1. Входной контроль Заявок на оплату».

2. Бизнес-процессы первого уровня:

Ф1.1. Платежи валютные;

Ф1.2. Платежи внутри страны.

Бизнес-процессы первого уровня также представляют из себя дерево.

3. Кодовое название элемента второго уровня — подпроцесс (обратите внимание, что термин «бизнес-процесс» меняем на термин «подпроцесс»). Подпроцессы являются ключевыми составляющими бизнес-процесса первого уровня. Например, подпроцессы бизнес-процесса «Ф1.2. Платежи внутри страны» следующие:

Ф1.2.1. Формирование и согласование Реестра платежей;

Ф1.2.2. Формирование платежных поручений в системе «Клиент-Банк»;

Ф1.2.3. Работа с выписками по расчетному счету;

Ф1.2.4. Отражение проведенных платежей на счетах бухгалтерского учета;

Ф1.2.5. Отражение проведенных платежей на статьях бюджета.

4. Кодовое название элемента третьего уровня — процедура (последовательность действий с промежуточным результатом).

Например, подпроцесс «Ф1.2.1. Формирование и согласование Реестра платежей» состоит из следующих процедур:

Ф1.2.1.1. Формирование Реестра платежей;

Ф1.2.1.2. Согласование Реестра платежей.

5. Четвертый уровень детализации — узкоспециализированные функции (действия) нижнего уровня, из которых состоят процедуры.

Представим действия процедуры «Ф1.2.1.1. Формирование Реестра платежей»:

Ф1.2.1.1.1. Входной контроль Заявок на оплату;

Ф1.2.1.1.2. Внесение Заявок на оплату в Реестр платежей.

Покажем на примере, почему важна такая детализация.

ПРИМЕР

Компания ООО «Доминант» (г. Владимир) должна оплатить ООО «Торговый центр» (г. Владимир) аренду торговых площадей. Казначей не оплатит Заявку на сумму 25 300 руб. без выполнения процедур:

  • «Формирование Реестра платежей», которая включает следующие обязательные действия:

— Входной контроль Заявки (действие первое);

— Внесение заявки в Реестр платежей (действие второе);

  • «Согласование Реестра платежей», которая включает такие действия:

— Выбор приоритетных платежей «на сегодня» (действие первое);

— Согласование Реестра приоритетных оплат с финансовым директором (действие второе).

Когда выполнены указанные действия и процедуры, разрешается переходить к подпроцессу «Формирование платежных поручений в системе «Клиент-Банк”» и т. д.

Указанная терминология «бизнес-процесс – подпроцесс – процедура – действие» не является единственно возможной и единственно правильной. Каждая компания может применять удобную для нее терминологию, в зависимости от специфики бизнес-процессов и уровня детализации.

Описание бизнес-процессов до определенного уровня призвано:

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

БИЗНЕС-ПРОЦЕССЫ В ВИДЕ БЛОК-СХЕМ

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

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

Подпроцесс «Ф1.2.1. Формирование и согласование Реестра платежей», описанный ранее в табличной форме, в виде блок-схемы изображен на рис. 2.

Общепринято использовать формы блоков в соответствии с ГОСТ 19.701-90 «Единая система программной документации. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения».

Важная деталь: рабочая группа вправе упростить блок-схему, использовать блоки в значениях, отличных от ГОСТа. Главное, чтобы Владелец процесса, Заказчик и Руководитель проекта, Аналитики, Эксперты и непосредственные исполнители понимали их значение. Блок-схему можно создать с помощью различных программных продуктов (например, MS Visio, MS Word).

Регламентация финансовых бизнес-процессов:

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

Автор(ы): Д.Макаренко, А.Кравченко

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

Оставить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *