Как DIRECTUM повлиял на пересмотр регламентов в одной компании
Ситуация следующая: в компании утвердили положение по инициации, согласованию и утверждению договоров. Тут же было принято решение автоматизировать процесс согласно новому регламенту с помощью системы DIRECTUM. Владельцы бизнес-процесса за счет автоматизации хотели исключить случаи нарушения регламента и ускорить сроки заключения договорных документов. Рядовые сотрудники видели плюсы в том, что после автоматизации не надо будет ходить с бумагой по всем согласующим.
Для решения поставленной задачи были разработаны типовые маршруты и проведена тестовая эксплуатация с группой ведущих пользователей. Когда результат устроил заказчика, было проведено обучение рядовых пользователей и запущена опытная эксплуатация. Первый же договор, который являлся типовым на небольшую сумму, вместо привычных всем двух-трех дней согласовывался в системе… две недели.
Первые мысли заказчика, конечно же о том, что система дала сбой. Мы вместе проверили маршрут, и как проходил этот документ от начала и до конца – претензий не обнаружилось. Тогда вопрос, если система работала правильно, то каким образом договоры на бумаге согласовывали за пару дней? Проведенное расследование показало:
- Сотрудники, работая с бумагой, не застав на месте одного согласующего несли документ другому, что вполне резонно. Но владельцы бизнес-процесса, юристы, были решительно против – при согласовании договора необходимо соблюдать последовательность согласующих: обязательно сначала необходимо согласовать в своем подразделении, а потом согласовывать у прочих специалистов; сначала надо проверить строительную готовность и только потом закупать материалы и т.д. Иначе есть риск подписать договор, на который у компании нет ни средств, ни готовности.
- Иногда, какие-то специалисты пропускались в согласовании некоторых договоров, о них либо забывали, либо считали, что необходимости в их подписи нет. А это уже грубое нарушение регламента, с чем и боролся заказчик, внедряя систему. Но с другой стороны, копая глубже, выяснилось, что действительно, для некоторых договоров можно сократить круг согласующих.
Однако, даже признавая правильность работы системы, заказчика решительно не устраивали сроки согласования, и встал вопрос по оптимизации процесса. В первую очередь необходимо было найти системные/технические точки оптимизации, минимально затрагивающие регламент компании.
Сразу оговорюсь, что возможность сокращения срока согласования для конечного согласующего не рассматривалась, как точка оптимизации, т.к. ввиду иной работы, помимо согласования, и возможного отсутствия на рабочем месте согласующего, это бы привело к увеличению просроченных заданий, что искусственно занизило бы исполнительскую дисциплину, но никак не привело бы к ускорению согласования.
Итак, что в рамках поставленной задачи было сделано для заказчика?
Пересмотр категорий и видов договоров. Выделение типовых договоров
Самое первое и простое – это детализировать имеющийся перечень видов и категорий договорных документов с целью выделения для каждого своего списка согласующих и правил согласования. В итоге:
- вместо первоначальных семи категорий стало тринадцать. В согласующие по категориям договоров входили профильные специалисты, и при расширении списка категорий получились и такие, где профильные согласующие вовсе отсутствовали;
- все договоры были поделены на две большие группы – одну подписывал генеральный директор, вторую подписывал первый заместитель. Это позволило разгрузить директора, и дало возможность одновременного подписания договоров из разных групп;
- были выделены определенные виды договоров, которые заключались с одним и тем же поставщиком. Проект договора с этим поставщиком стал «типовым» для компании, что позволило согласовывать такой договор по правилам типовых;
- были разработаны шаблоны и типовые формы договоров, в которых основные пункты совпадали, и менялся только контрагент, срок и сумма. Для таких типовых договоров в типовом маршруте пропускался целый блок согласования проекта договора и договор сразу уходил на визирование и подписание. Вот здесь пришлось пересмотреть регламент заказчика, поскольку первоначальная версия не допускала пропуска этапа согласования проекта договора. К слову, разработка типовых проектов договоров ведется у заказчика и в настоящее время. Постепенно, все больше видов/категорий договоров становятся типовыми.
Объединение заданий на согласование, если согласующий совмещал несколько ролей
Рассмотрим цепочку согласования: исполнитель отправляет договор на согласование, первым согласующим является непосредственный руководитель, далее руководитель центра финансовой ответственности (ЦФО) и затем специалист проектно-технического управления (ПТУ). К примеру, если руководитель исполнителя одновременно является и специалистом ПТУ, тогда задание на согласование он получал один раз на этапе согласования с руководителем. Казалось бы, ничего сверхъестественного. Но это опять не соответствовало в точности регламенту:
- нарушалась последовательность: в этой ситуации специалист ПТУ согласовывает раньше руководителя ЦФО. Однако, правила в компании не столь бюрократизированы и жестки, что владельцы процесса пошли на это отклонение. В результате в регламенте и инструкциях прописали, а пользователям провели инструктаж, что в таких случаях согласующий обязан рассмотреть все пункты договора, которые он согласовывает, как исполнитель нескольких ролей согласования;
- отсутствие нескольких подписей в листе согласования. Ранее, получив договор на согласование руководитель, если он же являлся согласующим от ПТУ ставил две подписи на бумажном листе согласования. В текущей схеме, при согласовании в системе в листе согласования присутствовала только одна подпись, что также было согласовано с заказчиком.
Возможность выбора согласующих на повторных кругах согласования
Согласование договорных документов в компании состоит из 4 этапов, на каждом из которых свой круг специалистов, согласующих договорной документ и свои ответственные (те, кто дорабатывает документ по замечаниям):
- согласование заявки на договор – ответственный за этап исполнитель
- согласование проекта договора – ответственный за этап юрист, подготовивший проект договора
- согласование договора после закупочной процедуры (тендер/переговоры) – ответственный за этап исполнитель
- визирование и утверждение договора – ответственный за этап юрист
Если у кого-либо из согласующих были замечания, проект договора отправлялся на доработку и после нее согласовывался повторно со всеми специалистами. Таким образом исключался риск, что кто-то из согласующих пропустит изменения, коснувшиеся пунктов, за которые он ответственен. Однако, даже самые незначительные доработки существенно увеличивали срок согласования, а большинство согласующих не понимало зачем им повторно согласовывать документ, если правки незначительны.
В итоге на этапах согласования проекта договора и визирования договора для юриста на этапе доработки была сделана возможность выбора списка согласующих для повторного согласования. По умолчанию список заполнялся теми согласующими, которые высказали замечания, но у юриста была возможность добавить согласующих, если по итогам доработки изменения коснулись и других пунктов.
Для реализации такой возможности с минимальными рисками в компании были выделены два юриста, отвечающие за подготовку проектов договоров, и несущие ответственность, что проект договора будет согласован со всеми необходимыми специалистами. При этом на остальных двух этапах у исполнителей отсутствовала такая возможность и им было необходимо повторно согласовывать договор со всеми своими согласующими на данном этапе.
Приведенные выше мероприятия к изначальным двум дням согласования не привели. Сейчас средний срок согласования типового договора составляет 5-6 рабочих дней. Это объясняется тем, что, как и просил заказчик, регламент сильно не менялся.
Подведем итоги: регламенты, оторванные от жизни, работать не будут. Поэтому перед введением новых положений в эксплуатацию необходимо тщательно исследовать текущее положение дел. Если в разных случаях процесс проходит по-разному, необходимо разобраться правильно ли это, либо действительно нарушение. А также нужно понимать, что жесткие регламенты могут повысить риски увеличения сроков, бюрократии и излишней работы.
На нашем примере видно, что оптимизировать работу с помощью одной только системы невозможно, необходим пересмотр регламента, чем сейчас и занимается заказчик. Ждем от него нового положения и сопутствующих пожеланий к типовым маршрутам.
Ксения, подскажите, как и кем обрабатывались возражения от инициаторов договоров. Уверен, что недовольство в любом появилось из-за увеличения сроков согласования.
Встало ли высшее руководство организации на защиту автоматизированных регламентов или все возражения обрабатывала проектная команда? Собиралась ли статистика по возможным упущенным сделкам по причине долгого согласования договорных документов?
У нас такая же ситуация с электронными актами. После внедрения процесс их обработки увеличился в разы, так как теперь не удается обойти стандартные процедуры и внести документ по копии или быстро пробежаться по кабинетам. Вроде по сути процесс абсолютно правильный, но желаемого упрощения работы не принес. Пока бухгалтерия тихо ропщет, но бунт уже скоро
Тимур, да, все верно, пользователи высказывали недовольство из-за увеличившихся сроков. И первой линией таких атак, разумеется были консультанты, т.е. мы :) По таким возражениям всех направляли к юристам - владельцам бизнес-процесса, потому что наша задача заключалась в перекладывании их регламента на систему. Мы можем лишь порекомендовать какие-либо мероприятия/изменения, но не требовать.
В этой ситуации юристы и руководство сами были заинтересованы в оптимизации, поэтому никто особо не противился пересмотру регламента. Но также было понимание, что слепо упрощать и сокращать процесс согласования нельзя, ведь тогда получится автоматизация хаоса. Поэтому сначала были приняты самые простые и, на взгляд заказчика, действенные меры, о которых я писала. А сейчас идет работа по поиску дальнейших точек оптимизации. Пока заказчик двигается к приведению бОльшего количества договоров к типовым. К слову, это действительно лучше прочих мер ускорило процесс.
Статистика не собиралась, потому как сделок упущено не было - начало опытной было построено таким образом, что согласование дублировалось на бумаге первые 2-3 недели. Как раз за это время были внесены вышеописанные корректировки, и процесс стал "выносимым". Да, недовольство рядовых пользователей все еще присутствует, но в гораздо меньшей степени, т.к. они видят, что процесс оптимизации не стоит на месте.
Максим, очень хорошо понимаю вас. Но тихо роптать не стоит - нужно раз за разом доносить замечания ответственным за процесс, собирать совещания, выдвигать предложения, на крайний случай, как вы писали, бунтовать :) Вряд ли руководству важна автоматизация ради автоматизации, и если у вас есть конструктивные замечания/предложения, я уверена, что к вам прислушаются.
Но также хочу отметить, что обычно, за автоматизацией стоит цель не столько упростить, сколько сделать правильным процесс. Например, в моей ситуации, были случаи, когда согласовывали одну версию договора, а подписывалась другая. Когда проект договора от заказчика терялся и многое, многое другое. Как раз для исключения таких случаев, нужны более жесткие инструменты, которые возможно, увеличат сроки согласования. И упростить, ускорить возможно только до какой-то определенной точки.
Максим, в данном случае надо исходить из целей, которые ставило руководство организации перед автоматизацией. Я думаю, что основная цель была снизить финансовые риски связанные с вероятной пропажей документа или некорректной его обработки.
Как правило СЭД не облегчает "механическую" работу пользователя, банально кликов мыши становится больше. СЭД должна повысить эффективность работы всего предприятия в целом. Если взять ваш пример с электронными актами, то да, время затрачиваемое на процесс обработки увеличилось, но при этом акт уже не потеряется в в одном из кабинетов и не будет отложен в дальний ящик, не будет пропущена важная виза, прозрачность процесса поможет проконтролировать его корректное и оперативное прохождение по этапам. При этом поиск исторических данных будет облегчен и ускорен в разы.
Не стоит ожидать эффекта сразу после внедрения, плюсы от использования СЭД будут очевидны только при долговременной эксплуатации. Это и нужно донести до бунтовщиков.
Ксения, очень знакомый случай, когда хотели сделать лучше, а по факту инициаторы возмущаются что раньше было быстрее( конечно быстрее, если делать в обход установленных процедур! Плавали - знаем!
А не было таких ситуаций, когда в организации был утвержденный вышестоящей организации бланк листа согласования, который самой организации с живыми подписями не нужен, а вот для вышестоящей обязателен. И это сводит весь процесс согласования в системе на нет.
Евгения, такой ситуации, к счастью, не было. В таком случае стоит вопрос о целесообразности системы, если в электронном согласовании нет смысла, тогда использовать только для хранения электронных документов и внутреннего взаимодействия?
У другого заказчика была похожая проблема: на техпроектах и прочих технических документах обязательно должны были стоять "живые" подписи согласующих, иначе "проверка не принимала" (с). Такие документы пришлось исключить из электронного согласования, зато прочие документы по делопроизводству и внутренние графики/планы хорошо прижились в СЭД. А это уже неплохое ускорение документооборота по компании в целом.
"в организации был утвержденный вышестоящей организации бланк листа согласования, который самой организации с живыми подписями не нужен, а вот для вышестоящей обязателен"
В этом случае не обязательно отказываться от электронного согласования и от его плюсов таких как параллельное согласование, соблюдение четкого регламента и простое делегирование полномочий.
Можно после электронного согласования прогонять бумажный комплект документов с листом согласования распечатанный из СЭД + лист согласования по требуемому образцу. Вычитывать документы повторно не требуется, а нужно просто поставить "живую" визу в ЛС.
Тимур, не всегда это допустимо. Бывают процессы, где существует риск подлога и высоки последствия такого подлога. Меры защиты от подлога бумажных документов могут быть разные. Например, установка собственноручной подписи на каждом листе документа. В этом случае, работа в системе так же не целесообразна до тех пор, пока не удастся убедить вышестоящую организацию работать с электронными документами и электронными подписями.
Михаил, согласен, риск подлога есть всегда, как при бумажном, так и электронном согласовании.
"Меры защиты от подлога бумажных документов могут быть разные. Например, установка собственноручной подписи на каждом листе документа." - аналогично при электронном согласовании можно проставлять "водяной знак" с информацией об ЭЦП в документ (хоть на каждой странице). Правда, это сразу приведет к ужесточению требований к форматам документов, а так же к высоким затратам на модификации системы, т.к. в коробочных версиях СЭД такого функционала нет.
Заказчик не любит идти на высокие расходы при не очевидном эффекте, а пойдет по более простому и менее затратному пути - оставит все на бумаге.
>>Например, установка собственноручной подписи на каждом листе документа
мы стали при распечатке автоматом преобразовывать документ в PDF и проставлять штампы с ИД и версией документа на каждой странице
отсутствие штампа - сигнал руководителю, что документ распечатан некорректно, а значит вероятен подлог
и да, наш лист согласования в вышестоящей организации воспринимают без проблем, форма наша, добавляется только ручная подпись управляющего директора
По поводу водяных знаков и штампов, мы на прошлом Awards писали... Штампы о подписях нужны только при печати документа. И так как в Directum нет отдельного события открытия текста документа с возможностью подменить содержание, то такую выгрузку имеет смысл делать только по кнопке на карточке или по пункту контекстного меню. Не имеет смысла сохранять штамп об электронных подписях в теле документа в системе, так как это меняет тело документа... Если работа организована в системе полностью, никакие штампы о подписях не нужны...
>>Штампы о подписях нужны только при печати документа. И так как в Directum нет отдельного события открытия текста документа с возможностью подменить содержание, то такую выгрузку имеет смысл делать только по кнопке на карточке или по пункту контекстного меню. Не имеет смысла сохранять штамп об электронных подписях в теле документа в системе, так как это меняет тело документа... Если работа организована в системе полностью, никакие штампы о подписях не нужны...
Михаил, все правильно, делали, кстати, с оглядкой на ваш опыт, при печати, мы в систему ничего не сохраняем, а только выгружаем из неё
а вот в случае с электронным утверждением, мы уже сделали простановку штампа ЭЦП в документ и конвертацию его в PDF. но это уже сделали для того, чтобы можно было документ распечатать, т.к. в электронке у нас все работать не могут
Авторизуйтесь, чтобы написать комментарий