Как DIRECTUM повлиял на пересмотр регламентов в одной компании

Опубликовано:
17 ноября в 09:59
  • 13

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

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

Первые мысли заказчика, конечно же о том, что система дала сбой. Мы вместе проверили маршрут, и как проходил этот документ от начала и до конца – претензий не обнаружилось. Тогда вопрос, если система работала правильно, то каким образом договоры на бумаге согласовывали за пару дней? Проведенное расследование показало:

  1. Сотрудники, работая с бумагой, не застав на месте одного согласующего несли документ другому, что вполне резонно. Но владельцы бизнес-процесса, юристы, были решительно против – при согласовании договора необходимо соблюдать последовательность согласующих: обязательно сначала необходимо согласовать в своем подразделении, а потом согласовывать у прочих специалистов; сначала надо проверить строительную готовность и только потом закупать материалы и т.д. Иначе есть риск подписать договор, на который у компании нет ни средств, ни готовности.
  2. Иногда, какие-то специалисты пропускались в согласовании некоторых договоров, о них либо забывали, либо считали, что необходимости в их подписи нет. А это уже грубое нарушение регламента, с чем и боролся заказчик, внедряя систему. Но с другой стороны, копая глубже, выяснилось, что действительно, для некоторых договоров можно сократить круг согласующих.

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

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

Итак, что в рамках поставленной задачи было сделано для заказчика?

Пересмотр категорий и видов договоров. Выделение типовых договоров

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

  • вместо первоначальных семи категорий стало тринадцать. В согласующие по категориям договоров входили профильные специалисты, и при расширении списка категорий получились и такие, где профильные согласующие вовсе отсутствовали;
  • все договоры были поделены на две большие группы – одну подписывал генеральный директор, вторую подписывал первый заместитель. Это позволило разгрузить директора, и дало возможность одновременного подписания договоров из разных групп;
  • были выделены определенные виды договоров, которые заключались с одним и тем же поставщиком. Проект договора с этим поставщиком стал «типовым» для компании, что позволило согласовывать такой договор по правилам типовых;
  • были разработаны шаблоны и типовые формы договоров, в которых основные пункты совпадали, и менялся только контрагент, срок и сумма. Для таких типовых договоров в типовом маршруте пропускался целый блок согласования проекта договора и договор сразу уходил на визирование и подписание. Вот здесь пришлось пересмотреть регламент заказчика, поскольку первоначальная версия не допускала пропуска этапа согласования проекта договора. К слову, разработка типовых проектов договоров ведется у заказчика и в настоящее время. Постепенно, все больше видов/категорий договоров становятся типовыми.

Объединение заданий на согласование, если согласующий совмещал несколько ролей

Рассмотрим цепочку согласования: исполнитель отправляет договор на согласование, первым согласующим является непосредственный руководитель, далее руководитель центра финансовой ответственности (ЦФО) и затем специалист проектно-технического управления (ПТУ). К примеру, если руководитель исполнителя одновременно является и специалистом ПТУ, тогда задание на согласование он получал один раз на этапе согласования с руководителем. Казалось бы, ничего сверхъестественного. Но это опять не соответствовало в точности регламенту:

  • нарушалась последовательность: в этой ситуации специалист ПТУ согласовывает раньше руководителя ЦФО. Однако, правила в компании не столь бюрократизированы и жестки, что владельцы процесса пошли на это отклонение. В результате в регламенте и инструкциях прописали, а пользователям провели инструктаж, что в таких случаях согласующий обязан рассмотреть все пункты договора, которые он согласовывает, как исполнитель нескольких ролей согласования;
  • отсутствие нескольких подписей в листе согласования. Ранее, получив договор на согласование руководитель, если он же являлся согласующим от ПТУ ставил две подписи на бумажном листе согласования. В текущей схеме, при согласовании в системе в листе согласования присутствовала только одна подпись, что также было согласовано с заказчиком. 

Возможность выбора согласующих на повторных кругах согласования

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

  • согласование заявки на договор – ответственный за этап исполнитель
  • согласование проекта договора – ответственный за этап юрист, подготовивший проект договора
  • согласование договора после закупочной процедуры (тендер/переговоры) – ответственный за этап исполнитель
  • визирование и утверждение договора – ответственный за этап юрист

Если у кого-либо из согласующих были замечания, проект договора отправлялся на доработку и после нее согласовывался повторно со всеми специалистами. Таким образом исключался риск, что кто-то из согласующих пропустит изменения, коснувшиеся пунктов, за которые он ответственен. Однако, даже самые незначительные доработки существенно увеличивали срок согласования, а большинство согласующих не понимало зачем им повторно согласовывать документ, если правки незначительны.

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

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

 

Приведенные выше мероприятия к изначальным двум дням согласования не привели. Сейчас средний срок согласования типового договора составляет 5-6 рабочих дней. Это объясняется тем, что, как и просил заказчик, регламент сильно не менялся.

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

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

18
Подписаться

Комментарии

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

Михаил, согласен, риск подлога есть всегда, как при бумажном, так и электронном согласовании. 

"Меры защиты от подлога бумажных документов могут быть разные. Например, установка собственноручной подписи на каждом листе документа." - аналогично при электронном согласовании можно проставлять "водяной знак" с информацией об ЭЦП в документ (хоть на каждой странице). Правда, это сразу приведет к ужесточению требований к форматам документов, а так же к высоким затратам на модификации системы, т.к. в коробочных версиях СЭД такого функционала нет.

Заказчик не любит идти на высокие расходы при не очевидном эффекте, а пойдет по более простому и менее затратному пути - оставит все на бумаге. 

>>Например, установка собственноручной подписи на каждом листе документа

мы стали при распечатке автоматом преобразовывать документ в PDF и проставлять штампы с ИД и версией документа на каждой странице

отсутствие штампа - сигнал руководителю, что документ распечатан некорректно, а значит вероятен подлог

 

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

По поводу водяных знаков и штампов, мы на прошлом Awards писали... Штампы о подписях нужны только при печати документа. И так как в Directum нет отдельного события открытия текста документа с возможностью подменить содержание, то такую выгрузку имеет смысл делать только по кнопке на карточке или по пункту контекстного меню. Не имеет смысла сохранять штамп об электронных подписях в теле документа в системе, так как это меняет тело документа... Если работа организована в системе полностью, никакие штампы о подписях не нужны...

Михаил Тарасов: обновлено 23.11.2017 в 11:41

>>Штампы о подписях нужны только при печати документа. И так как в Directum нет отдельного события открытия текста документа с возможностью подменить содержание, то такую выгрузку имеет смысл делать только по кнопке на карточке или по пункту контекстного меню. Не имеет смысла сохранять штамп об электронных подписях в теле документа в системе, так как это меняет тело документа... Если работа организована в системе полностью, никакие штампы о подписях не нужны...

Михаил, все правильно, делали, кстати, с оглядкой на ваш опыт, при печати, мы в систему ничего не сохраняем, а только выгружаем из неё

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

Авторизуйтесь, чтобы написать комментарий