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

Для определенности — возьмем типичную для СНГ крупную розничную сеть с сотнями магазинов в десятках городов немаленькой страны и миллионами клиентов.

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

В 99,9% случаев договорные отношения с покупателями вне зависимости от количества последних полностью стандартизованы.

Совершенно противоположная картина с поставщиками.

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

Что поставляют ПВО:

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

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

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

Некоторые характеристические мазки из жизни Юлмарта (картина, естественно, «до») — только что касается арендных отношений:

• «учет» построен на сотнях монстрообразных экселей.
• постоянно забывали своевременно делать заявки на оплату — попадание на пени.
• по аренде, как правило, вносится обеспечительный платеж. Про него регулярно забывали или, если последний месяц аренды не полный, а обеспечительный платеж был сделан на полный месяц, то разницу забывали считать. Итог — переплата.
• понедельный план арендных платежей для казначейства делался (естественно) вручную — в очередном экселе. Естественно — с кучей ошибок. Казначейство либо брало лишние кредиты на оплату по аренде (и выплачивало лишние проценты), либо денег на своевременную оплату не хватало, — попадание на пени.
• забывали отражать в системе затраты по аренде — постоянно. Итог — существенно недостоверный P&L.
• контроль бюджета: при заключении договора был на глазок. Если договор на крупную сумму — то пытались контролировать (с переменным из-за человеческого фактора успехом). А если сумма относительно небольшая, то никто и не рыпался. Nuff said.

Ежегодные потери измерялись миллионами. 
И это, напомним, — только по аренде.

Численно-вербальным образом удалось убедить ответственных товарищей из Юлмарта: пора кончать.
В итоге в рамках dia$par, развернутого в Юлмарте, был внедрен механизм управления договорными отношениями.

В абстракции IEM-модели данных dia$par договор, в сущности, является

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

Объекты

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

Шапка документа «договор» содержит следующую информацию:

• от какого юридического лица заключается договор с нашей стороны
• контрагент-поставщик
• с какого расчетного счета предполагаются платежи
• валюта договора

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

Если договор заключается с физическим лицом, то активируется закладка с параметрами по налогам. Система по умолчанию автоматически будет формировать вторую заявку на оплату в налоговый орган с суммой НДФЛ (умолчание, естественно, отключабельно :)

При создании нового документа «договор» инициатор прикладывает бинарную версию (*.doc, *.jpg etc) для подписания.

Движение договоров

Инициатор изначально создает документ в подтипе «Заявка на договор» (черновик) и переводит в подтип «На подписание».

На этом этапе определяются подписанты:

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

Обсуждение договора:

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

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

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

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

Контроль бюджета может вестись в двух режимах:

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

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

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

• a) dia$par в этом случае создает заявки самостоятельно и всегда вовремя
• b) заявку, созданную из договора, подписывает всего лишь один сотрудник — финансовый контролер. Соответственно, процесс утверждения практически мгновенен, и визированная заявка моментально переходит в область ответственности казначейства. В обычном же случае (без использования механизма договоров) подписание проходит через ответственного за статью затрат, финансового директора, руководителя управления, регионального директора, бухгалтера... Такой процесс характерен для каждой крупной компании со среднестатистическим уровнем бюрократии.

Процессинг платежей

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

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

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

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

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

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

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

Особо отметим, что этот прогноз строится полностью автоматически.

Процессинг затрат

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

Как же изменилась картина бытия фиников Юлмарта после внедрения вышеописанных features?
 

Платежи идут строго в рамках бюджета.
Согласование платежей занимает минимум времени — 0 лишних телодвижений с подписями, а у казначейства уже зарезервированы деньги, чтобы платить как полагается.
Помимо прочего, это позволило Юлмарту сократить до нуля сумму потерь по арендным платежам (сотни арендуемых объектов). Миллионы с неба.
Приглядыванием за всеми арендными платежами занимается всего один человек — в формате дополнительный нагрузки к основным финиковым обязанностям — «Работает? Ну и не трогай».

Вот это эффективный менеджмент.
Ну нам, по крайней мере, так кажется.

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

P.S. Особенно яркие ощущения от результатов сравнения должны испытать сотрудники компаний-эксплуатантов невозможно авторитетных «систем автоматизации документооборота» — стоимостью от сотен тысяч долларов (самые нищебродские варианты).