Декомпозируем третью функцию (А3) на более детальный уровень и переходим в нотацию BPMN, с использованием которой можно описать модель конкретных действий всех сотрудников. Еще раз поясним, что это пример. В каждой организации эти процессы выстраиваются по-разному, так, как это в каждом отдельном случае будет эффективно. Соответственно АСУ ТМА Казначейство также перенастраивается (адаптируется) в соответствии с этим процессом.
Обычно в автоматизированных системах управления денежными потоками реестр утвержденных заявок и является реестром на оплату. Но на практике заявки должны проходить цепочки оформления, согласования и утверждения заблаговременно, а иногда задолго до дня оплаты. Это обеспечивает хорошо проработанный платежный календарь далеко в будущее и заранее предвидеть все неприятности относительно нехватки или избытка денег. К моменту наступления дня оплаты ситуация может меняться, а заявка может оставаться в реестре утвержденных заявок. Кроме этого, в день оплаты может возникать ситуация, что банально не хватает денег, чтобы произвести все оплаты. К примеру, в предыдущий день не поступили все запланированные поступления. Поэтому даже в базовой версии процесса в системе ТМА Казначейство формирование реестров на оплату выделено в отдельный подпроцесс, в ходе которого производится согласование и утверждение уже самого реестра не только на уровне руководства, но и на уровне линейных руководителей. Руководители подразделений, ответственные за их локальный реестр оплат гораздо лучше кого-либо знают кому надо платить обязательно, кому можно заплатить частично, а кому вообще не надо платить. При большом количестве повседневных оплат выделение в отдельный подпроцесс в значительной степени повышает эффективность, точность, безошибочность проведения оплат.
Казначей – это роль, которую обычно выполняет финансовый директор.
День оплаты – это день, когда происходит процедура формирования реестра на оплату и непосредственно оплата. В некоторых организациях выделяются определенные дни недели, в других каждый рабочий день.
В день оплаты Казначей исходя из текущей ситуации остатков денежных средств согласует и вносит в систему лимиты по локальным реестрам (подразделениям или ЦФО). Тут главное не перепутать, поскольку понятие Лимиты в казначействе встречается дважды. Один раз – это по статьям и подразделениям на период. Их можно внести вручную или загрузить из системы бюджетирования. По ним контроль происходит при согласовании каждой отдельной заявки. А в нашем случае – это лимит денег на локальный реестр (чаще всего это подразделение или ЦФО) на в конкретный день оплаты.
Пример.
В ИТ отделе сегодня стоит 500 000 рублей по 10 заявкам, 300 из которых закупка сервера, остальное обязательные платежи.
Примечание. Обязательные платежи – это обычно такие платежи, не заплатив которые, произойдет нежелательное событие, к примеру, отключат мобильную связь.
По результатам вчерашнего дня какой-то клиент сделал ошибку в реквизитах и деньги до нас не дошли. У финансового директора около 20 млн. на выплате по 15 локальным реестрам, и всем надо платить позарез, а есть возможность заплатить только 16 млн. Но в прочем, руководителя ИТ департамента мало интересует эта проблема, ему срочно нужно купить сервер, иначе сроки по проекту, за который он несет ответственность будут сорваны. Кроме того, компания понесет убытки, поскольку уже оплачены по договоренности специалисты, которые должны приехать устанавливать этот сервер. Одним словом, ему нужна вся сумма 500 тыс. рублей как воздух.
Не надо объяснять, что приблизительно такая же ситуация в остальных 15-ти ЦФО. И что начинается в результате!? Финдира начинают рвать на куски и каждый объясняет свою крайнюю необходимость, влоть до жизненно важной. Сколько времени уйдет, чтобы принять правильное решение? Или просто рубануть с плеча?
В нашем случае финдир (казначей) подрезал каждому подразделению небольшую сумму и в целом вышел на 16 млн. На это у него ушло 5 минут с утра, после того, как в казначейство были загружены банковские выписки, и он на своем рабочем столе системы АСУ ТМА Казначейство увидел неприятный сигнал о нехватке денежных средств для оплат и причину такой коллизии.
Директор ИТ департамента сразу получил сообщение, что его реестр на оплату урезали на 100 000 рублей. Т.е. у него лимит оплаты на сегодняшний день не 500, которые ему жизненно необходимы, а 400. От обязательных платежей он не может отказаться, иначе «отключат газ» и он сильно пострадает. Сервер так же нужен без вариантов. Немного подумав, он позвонил поставщику сервера и без труда договорился разбить платеж на две части. 200 он заплатит сегодня, а 100 в течение трех дней после поставки. 10 минут ушло на составление и отправку гарантийного письма и 5 минут на разбитие в заявке на оплату суммы на два платежа и утверждение своего локального реестра.
Надо думать в остальных ЦФО руководители без труда нашли свои решения подрезать свои реестры. Финдир в результате получил общий реестр на 16 млн, и уже к 11 утра отправил его на утверждение генеральному директору, не тратя время на выслушивание стонов руководителей подразделений и их локальных проблем. К часу дня все платежи были произведены. Если компания и пострадала от этой ситуации, то этот ущерб был минимальным.
В примере описаны два первых куска модели бизнес-процесса формирования реестров на оплату.
Казначей в любом случае согласует лимиты, но если денег хватает, то для этого достаточно одного нажатия.
Руководитель реестров в любом случае согласует свой локальный реестр, но если денег хватает, то для этого также достаточно одного нажатия.
В результате финдир знает и понимает общую ситуацию по оплатам, а каждый линейный руководитель знает и понимает свою локальную ситуацию по оплатам и может заниматься своими непосредственными обязанностями.
Если в 11 утра казначей видит, что какие-то локальные реестры не приведены в соответствие лимитам, то он сам переносит какой-то платеж этого ЦФО на другой день. На это у него уходит не более 10 минут. После чего он формирует общий реестр на оплату, который автоматически отправляется на согласование руководству.
Руководитель получает сообщение, которое может содержать полную информацию по реестру. Также в АСУ ТМА Казначейство он может мгновенно получить любую детальную информацию, и для этого не надо быть компьютерным гением. Он может обсудить с финдиром реестр по телефону или обмениваться сообщениями по реестру в АСУ ТМА Казначейство. В итоге он его утверждает, при необходимости попросив финдира внести корректировки.
Финдир (казначей) вносит корректировки по требованию руководства и утверждает реестр в оплату.
Реестр готов к оплате.
Но существуют исключительные случаи, когда необходимо срочно произвести оплату без бюрократических процедур, поэтому в регламенте и системе АСУ ТМА Казначейство такая ситуация должна быть предусмотрена.
В этом варианте идет прямое распоряжение руководства оператору казначейства (экономист или бухгалтер) о проведении срочной оплаты, т.е. без предусмотренных регламентом обычных процедур.
Оператор казначейства в первую очередь проверяет наличие заявки в системе, если заявки нет, то он ее вносит и по ней по специальной процедуре в АСУ ТМА Казначейство проводит оплату.