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

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

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

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

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

К 99,9% случаев договорные отношения с покупателями (а даже покупка йогурта в какой-нибудь Пятерочке — частный случай договорных отношений, публичная оферта + чек) вне зависимости от количества последних полностью стандартизованы.

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

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

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

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

Примечание Ultima Consulting.
Собственно, такое положение вещей справедливо для любой конторы не Никанора.
Более того, развивая эту мысль — жесткая стандартизация бизнес-процессов обслуживания потребителей — и есть основное отличие организованного бизнеса от молодой, динамично развивающейся компании  — вне зависимости от размеров.

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

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

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

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

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

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

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

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

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

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

Активные товарищи из vnedr.com численно-вербальным образом убедили ответственных товарищей из Юлмарта: пора кончать.
В итоге в рамках решения Ultimate e-Trade, развернутого в Юлмарте, был внедрен механизм управления договорными отношениями.

В абстракции e-Trade договор, в сущности, является

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

Объекты

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

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

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

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

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

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

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

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

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

Подписанты

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

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

Комментарии

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

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

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

Превышение бюджета в строках
Превышение бюджета в строках (моб)

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

Превышение бюджета в шапке

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

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

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

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

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

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

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

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

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

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

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

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

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

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

План по договорным платежам

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

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

Как же изменилась картина бытия фиников Юлмарта после внедрения вышеописанных features?
Как обычно, товарищи: «на земли мир, во человецех благоволение» (Евангелие от Луки, гл. 2, ст. 14)

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

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

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

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


Подробнее об используемых компонентах: Ultimate MobileView

Материалы из библиотеки атеиста Powered by Ultima Consulting


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

Powered by Сон разума