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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

Комментарии

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

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

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

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

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

 

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

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

 

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

У другого заказчика была похожая проблема: на техпроектах и прочих технических документах обязательно должны были стоять "живые" подписи согласующих, иначе "проверка не принимала" (с). Такие документы пришлось исключить из электронного согласования, зато прочие документы по делопроизводству и внутренние графики/планы хорошо прижились в СЭД. А это уже неплохое ускорение документооборота по компании в целом. 

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

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

Можно после электронного согласования прогонять бумажный комплект документов с листом согласования распечатанный из СЭД + лист согласования по требуемому образцу. Вычитывать документы повторно не требуется, а  нужно просто поставить "живую" визу в ЛС.

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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