Как было
До реализации проекта предприятие было классическим образцом предприятия с традиционными для постсоветского делопроизводства процессами – беготней с бумажками по кабинетам, листами для резолюций и согласований, а значит — безответственностью исполнителей. В руководстве долгое время шли разговоры о том, что текущая система согласования документов несовершенна: часто в процессе согласования терялись документы, подменялись отдельные листы уже согласованных документов непосредственно перед подписанием, и виноватых найти было невозможно. Поручения по документам тоже выдавались по старинке: секретарь, получая входящий документ по электронной почте, распечатывал его на принтере и делал отметку в журнале регистрации, затем прикладывал к документу листок для резолюции, нес ее директору, а тот ставил резолюцию на документ с назначением исполнителя. Затем эта бумажка с документом возвращалась секретарю, который сканировал и резолюцию, и документ и отправлял файл назначенному исполнителю по электронной почте.
При такой системе выдачи поручений никакого контроля за их исполнением и быть не могло. Файлы, отправленные ответственным исполнителям по почте, улетали в никуда, а фраза «мне ничего не приходило» звучала все чаще. Приходилось тратить время на доказательство того, что файлы все-таки были отправлены. Один из вариантов решения проблемы — в ручном режиме отслеживать ход исполнения каждого поручения, но для этого нужно иметь штат делопроизводителей-контролеров, но его не предвиделось. Такая «система» породила беспредельное отсутствие контроля и безответственности исполнителей на местах. Однако дело не двигалось.
В декабре 2015 года я озвучил руководству мысль: если мы не начнем работу по переходу на современный уровень управления предприятием немедленно, мы рискуем отстать от конкурентов, которые уже начали активно переходить на современные технологии управления своим бизнесом. Тем более, что необходимая нормативно-законодательная база в стране существовала уже давно. Для принятия решения о внедрении системы недоставало реальных цифр, и я сел за расчеты.
С одной стороны, нужно было понять сколько предприятие теряет при текущих механизмах управления, а с другой — оценить стоимость трудозатрат при повышении эффективности управления. При оценке я брал процессы, которые планировал автоматизировать, ежемесячную нагрузку (число операций по процессам), среднюю заработную плату сотрудников, которые принимают участие в этих процессах. Получалось, что на существующей процедуре согласования договоров предприятие теряло ежегодно 2 000 000 рублей, на процессах обработки входящей, исходящей и внутренней корреспонденции — 850 000 рублей, на процедурах поиска необходимой информации — 350 000. На контроль исполнительской дисциплины мы не тратили ничего, потому что не вели его. А это имело хоть и привычные для бизнеса, но пагубные последствия — срыв сроков исполнения обязательств по исполнению контрактов, пени, судебные разбирательства с заказчиками и подрядчиками.
С учетом потенциальных трудозатрат на контроль исполнительской дисциплины получался экономический парадокс: чтобы сэкономить с помощью повышения эффективности управления, нам бы потребовалось увеличить трудозатраты как минимум на 4,5 млн рублей ежегодно. Мои цифры показали очевидное: в перспективе предприятию было выгоднее переходить на систему электронного документооборота, а именно: автоматизировать работу с организационно-распорядительными документами предприятия, автоматизировать работу по согласованию договорных документов, усовершенствовать механизмы выдачи и контроля исполнения поручений руководителя.
Выбор платформы и поставщика услуг, защита проекта
СЭД выбирается не на один год, а с перспективой минимум на пять лет, поэтому на данном этапе мне предстояло найти технологичное решение, которое бы вписывалось в бюджет предприятия; было разработкой известного на рынке производителя ПО; у производителя были партнеры для внедрения. Помимо этого — выбрать надежного подрядчика, подготовить и защитить проект перед руководством; заключить договор.
Я начал изучать рынок систем: заказывал презентации, консультировался со специалистами по ИТ, сравнивал. Моими требованиями к платформе были: возможность администрировать и поддерживать ее силами предприятия после внедрения, наращивание функционала платформы по мере необходимости, определенная стоимость программного обеспечения и лицензий, отечественный производитель. По всем параметрам подошла платформа российского производства Docsvision. Осталось в максимально сжатые сроки определиться с окончательным бюджетом внедрения и найти надежного поставщика услуг по разработке и поставке нужной нам конфигурации.
Чтобы точно определить бюджет проекта и избежать финансового перерасхода в будущем, я проанализировал исходные данные: анкетировал структурные подразделения и определил виды документов, работу с которыми предполагалось автоматизировать в проекте, описал внутренние процессы, уточнил количество пользователей системы. На основании этих данных, я запросил коммерческие предложения у десятка партнеров Docsvision. При оценке предложений я обращал внимание на наличие у поставщика коробочного решения, которое можно было бы в минимальные сроки конфигурировать под наши требования. После проведения цикла собеседований с потенциальными поставщиками адекватный бюджет проекта был сформирован.
Я представил бюджет проекта на рассмотрение руководству. Так, финальная стоимость проекта (с учетом услуг подрядчика, необходимого аппаратного и программного обеспечения) составила 3 млн, что в будущем позволяло экономить предприятию трудозатраты на повышение эффективности работы в 4,5 млн рублей ежегодно. В апреле 2016 года я успешно защитил бюджет проекта перед руководством и заключил договор на внедрение.
Подготовка к внедрению
Я, как представитель заказчика, должен был наладить коммуникацию между заинтересованными подразделениями и подрядчиком, совместно с подрядчиком тщательно проанализировать и формализовать текущие бизнес-процессы, подлежащие автоматизации. Чтобы автоматизировать бизнес-процессы с учетом наших требований, нужно было разложить все маршруты движения документов, утвердить шаблоны документов, определиться с политикой доступа к информации и прочие мелкие, но важные детали. Этим мы и занимались с подрядчиком на протяжении месяца. И к середине мая 2016 дизайн-проект нашей системы был готов. Началась разработка, которая была завершена к концу июня 2016 года. После проведения приемки конфигурации и устранения выявленных недочетов все было готово к запуску системы в опытную эксплуатацию.
В июле 2016 я организовал групповое обучение 100 пользователей системы. Мы с командой планировали одним махом запустить в эксплуатацию широкую функциональность, поэтому целью обучения было обучить персонал только основным понятиям и навыкам с тем, чтобы все остальные возможности системы пользователи освоили в процессе эксплуатации. Еще одним условием при обучении было провести его максимально быстро, чтобы пользователи прошедшие обучение в первых группах (по 5-7 человек), не успели растерять знания к моменту запуска системы в эксплуатацию. С этой целью я объединил группы по возрастному принципу: первыми проходили обучение более молодые пользователи, затем люди старшего и пенсионного возраста. Таким образом, более старшие поколения не успели растерять полученные навыки к моменту запуска системы.
Опытная эксплуатация
При запуске системы в опытную эксплуатацию мы столкнулись с проблемой, которую я предвидел: отдельные пользователи хотели работать как прежде, пытались по привычке приносить бумаги на согласование в распечатке и т. п. Я был к этому готов. Чтобы развеять все сомнения у несогласных и избежать саботажа, я заранее подготовил все необходимые внутренние нормативные акты, легализирующие новые и отменяющие старые порядки. Кроме того, предварительно провел разъяснительные беседы с руководством и донес мысль, что успех опытной эксплуатации будет зависеть в том числе от твердой позиции «сверху», а главное от их активной работы в системе. Так удалось создать условия, при которых пользователям не осталось ничего другого, кроме как принять новые правила.
Как и ожидалось, в результате опытной эксплуатации мы с подрядчиком выявили ряд упущений и оперативно скорректировали конфигурацию системы.
Результаты
В сентябре 2016 года система была запущена в промышленную эксплуатацию. В ходе проекта была автоматизирована работа с организационно-распорядительной документацией, тендерно-договорная работа, контроль исполнительной дисциплины. Были достигнуты следующие результаты: в единое информационное пространство с центральным офисом объединены удаленные структурные подразделения предприятия, повышена степень взаимодействия подразделений предприятия в процессе согласования документации (сроки согласования документов снижены в 6 раз, сроки обработки входящих документов и выдачи поручений по ним — в 10 раз), на 100% исключена возможность потери и изменения документов в процессе их согласования и подписания, повышена безопасность доступа к информации, на 100% повышена степень исполнительской дисциплины сотрудников за счет усовершенствованных механизмов контроля.
По результатам внедрения и первых трех месяцев функционирования системы руководство поставило новую задачу — расширить функционал системы и автоматизировать работу отдела продаж.
О себе: Начальник общего отдела, в обязанности входит руководство подразделением, в том числе поддержка и развитие документационного обеспечения управления на предприятии.
Комментарии (31)
impetus
25.01.2017 14:14+3Вот бы эту же статью — но от тех, кто реально решал проблемы при этом внедрении.
Автор, вы извините, но многолетняя практика показывает, что таким дубовым канцеляритом, да ещё вообще без какой-либо конкретики — пишут чаще всего лишь те, кто ни в чём реально не участвует и, как правило, реального положения дел вообще не представляет.
azsx
26.01.2017 07:53В подобных СЭД самая большая проблема — это аутентификация клиента. Скажите, пожалуйста, как в предложенной СЭД решён данный вопрос?
Pavel_Gorshkov
26.01.2017 10:52Аутентификация в системе происходит во время входа пользователя в Windows (логин, пароль), все действия в системе автоматически подтверждаются простой ЭЦП (для внутреннего обмена информацией) и квалифицированной ЭЦП для подписания документов на выход из организации.
Порядок выдачи логинов и паролей, ответственность пользователей за их хранение определены внутренним нормативным актом (в соотв. с ФЗ-63 «Об электронной подписи»)adeyko
26.01.2017 16:39Круто. Многие ленятся делать single sign-on и несчастным пользователям приходится вводить логин и пароль чуть ли не в каждую систему которая у них есть.
azsx
27.01.2017 04:32Аутентификация в системе происходит во время входа пользователя в Windows (логин, пароль)
При работе с веб версией никакой идентификации по имени пользователя нет, верно? Также, а если я зашёл в windows и сменил имя пользователя, смогу видеть всё под его правами?
Круто.
Было бы круто не просто ру (е) токен с неоткрепляемой частью закрытого ключа в единственном экземпляре, а чтобы при подключении в usb токен противно пищал и человеческим голосом говорил имя пользователя сертификата. Многие работники, особенно руководители, безалаберно относятся к этим цифровым подписям. Вот такой голос — это было бы круто и сразу +80 уровней к защите. А если е токен всегда ещё и на сторону передавала все свои подключения (где, когда), так было бы мега круто.
А пока СЭД просто бызвыходность ситуации, печать подделать ещё проще, чем сертификат спереть.Nordicx86
27.01.2017 13:47А что вы предлагаете? Биометрика еще мене надежна… PIN-код токена тоже та еще лотерея…
Есть конечно идея — имплантируемые RFID+токен, но не просто, а вот так:
1. алгоритм с ключом в RFID — те в сам RFID зашит неизвлекаемый ключик и алгоритм преобразования по ключу и запросу генерится ответ.
2. RFID работает паре с USB токеном.
3. RFID читается не считывателем, а токеном напрямую — те для того что бы авторизовать процес подписывания надо поднести RFID (или руку с ним) ближе 20 см к Токену(в обычных условиях токен просто вставлен в USB разъем в мышке)
Собственно лучшего я пока не придумал — можно конечно обойтись просто RFID с неизвлекаемым ключом, но недолго и не очень надежно… а в описаном варианте можно реализовать вторичный механизм для подключения новых RFID скажем черезх «полную идентификацию» и мастер-ключ для серии токенов+RFID-ов.adeyko
01.02.2017 20:57Вы обсуждаете проблемы ЭЦП? Так это вам в другую дверь.
azsx
02.02.2017 01:50adeyko понимаете, по моему мнению сегодня любым СЭД можно пользоваться скорее от любви к гикам, а не потому, что ЭЦП удобнее подписей и печатей.
adeyko
02.02.2017 11:05Понимаете, что это мнение с каждым днем все менее применимо к реальному миру и противоречит прогрессу, а поэтому лучшее что вы можете сделать даже для себя — это его поменять?)
azsx
02.02.2017 15:46лучшее что вы можете сделать даже для себя — это его поменять
Сегодня сплошь и рядом назначают ответственного сотрудника, у которого одновременно работает несколько подписей разных руководителей. Также есть компьютерщик, у которого в общей свалке файлов в том числе все сертификаты. Как начну замечать, что всё не так — так сразу мнение и поменяю.
Здесь главное от старости не успеть помереть, пока прогресс шагает.
VVizard
31.01.2017 18:18Из моего опыта самая большая проблема в крупных холдингах, это роли и права доступа, самый АД начинается когда какой нибудь зам. гендиректора уходит в отпуск, его права делегируются 4м разным сотрудникам, т.к. разные люди работают с разными документами, один из них уходит на больничный, делегируя свои права пятому, причем тот может видеть только часть документа (например не доступна финансовая часть), затем выясняется что пятого нужно срочно перевести на другой проект и нужно передать права 6му, но 6му нужно больше прав чем было у 5го, причем все что делал 5й нужно откатить и продолжить БП уже по другой ветке, при этом уже 1,2,7,8 прошли свои ветки процесса почти до конца (да параллельные ветки в схеме БП это тоже проблема) и добавили соответствующие файлы.
Когда над документом работают 8-9 отделов в 5-6 филиалах (это человек 40) разбираться в том «почему у меня нет доступа» или «почему ему доступен документ» становится не просто.
Еще интересно когда документ согласуют много людей но каждый должен видеть только его часть, при этом у них есть кураторы и они должны видеть все в целом, плюс к этому ограничения по выводу на печать и сохранению в файл.adeyko
01.02.2017 20:59Первое — реальность везде. Поэтому нужны хорошие средства делегирования в СЭД.
Последнее, особенно про часть документа показывает, что имеет место неадекватный бизнес процесс, а те кто его проектировал игнорировали реальность, ограничения технологии, и логику. В какой вселенной можно дать человеку лист с текстом так, чтобы он видел только его часть?VVizard
02.02.2017 10:26Согласуются не только договора но и например бюджеты, проекты, так же есть документы специфичные именно для того бизнеса который мы автоматизировали. Часть документов представлены в виде таблиц где разные подразделения согласуют разные финансовые блоки.
Конечно многое решается орг. мерами, такие документы дробятся на более мелкие, затем для руководителей общий документ приходится собирать из кусочков. Есть еще масса особенностей, например, из за того что в филиалах разные штатные расписания, в разных филиалах одна и та же «Роль» может иметь доступ к разному составу информации, в итоге «кусочки» получаются для разных филиалов разные, появляются доп. объекты адресации у роли.
Я в основном занимался разработкой конструктора и выполнением разработанных схем т.е. мне можно сказать повезло и в моем случае задача была чисто техническая, реализовать набор блоков и логику их выполнения. Вся предметная область + остальные подсистемы касались меня косвенно. В моем случае больше всего проблем было с откатом БП до определенного состояния (с учетом выполненных действий и параллельных веток).
md_axel
27.01.2017 17:56А вы могли бы привести расчеты, которыми доказали необходимость внедрения?
Pavel_Gorshkov
27.01.2017 19:10Раскладываем процесс на операции, определяем участников процесса и вводим переменные:
a) время на операцию (мин.) b) количество операций в день, c) количество задействованных в операции сотрудников, d) ежемесячная плата участника операции (руб.).
Привожу пример расчета процесса работы с входящей корреспонденцией:
Операции
1)Вывод документа на печать (Секретарь)
а=0,2; b=7; с=1; d=55000
2)Вывод листа для резолюций на печать (Секретарь)
а=0,2; b=7; с=1; d=55000
3)Фиксация реквизитов документа в журнале регистрации, выделение номера (Секретарь)
a=2; b=7, c=1, d=55000
4)Передача документа на рассмотрение директору (Секретарь)
а=1; b=7; с=1; d=55000
5)Вынесение резолюции по документу и назначение исполнителя (Директор)
а=1; b=7; с=1; d=150000
6)Возврат документа с резолюцией секретарю (Секретарь)
а=1; b=7; с=1; d=55000
7)Добавление в журнал регистрации текста резолюции, исполнителя и срока исполнения (Секретарь)
а=2; b=7; с=1; d=55000
8)Сканирование документа с резолюцией и отправка исполнителю по эл почте (Секретарь)
а=1; b=7; с=1; d=55000
9)Подшивка документа в дело (Секретарь)
а=2; b=7; с=1; d=55000
Вычисляем ежегодные временные затраты по операции, пересчитываем затраты на рубли, суммируем стоимость всех операций и получаем стоимость затрат по конкретному процессу.
В конкретном случае ежегодная стоимость затрат по процессу работы с входящей корреспонденцией составила 121 589 руб.
После автоматизации процесса трудозатраты сократились в 10 раз, за счет полного исключения трудозатрат по операциям № 1,2,4,6,7,8,9 и оптимизации затрат по операциям № 3 и № 5.
После автоматизации секретарь просто перетаскивает файл из почты в папку СЭД — «Входящие» (при этом автоматически создается карточка документа), заполняет несколько полей и нажимает кнопку «Отправить на рассмотрение». Далее директор автоматически получает задание на рассмотрение, выносит резолюцию (при этом можно выбрать типовую резолюцию из списка, ничего не печатая), выбирает исполнителя/исполнителей из списка и нажимает одну кнопку «Рассмотрено». Все остальное делает система (в т.ч. ставит задание исполнителю и контролирует сроки).
Таким же методом рассчитываем трудоемкость других процессов и получаем общую стоимость затрат по предприятию.
AcidVenom
Каких еще вендоров рассматривали? Без сравнительного анализа это просто реклама.
Pavel_Gorshkov
Читал аналитические статьи по обзору платформ и получалось что выбор достойных вариантов реально большой. Своими глазами смотрел 1С Документооборот, несколько решений на Sharepoint, Docsvision. Почему я выбрал последнего — более 10 лет на рынке, много внедрений на данной платформе, большой выбор партнеров, гибкая лицензионная политика, наличие мощных конструкторов для самостоятельной модификации системы. В процессе эксплуатации всплывают, конечно, косяки, но разработчики оперативно выпускают обновления и это радует.
adeyko
Пример серьезного косяка который всплыл при внедрении и как решали — в студию!
Pavel_Gorshkov
Из последнего запомнился косяк, когда заваливался процесс согласования документов в тот момент, когда исполнители добавляли к согласуемым документам дополнительные информационные файлы. Мне приходилось принудительно останавливать согласование и запускать процесс повторно. При разборе выяснилось, что ошибка платформенная и уже вендору известная, ее пофиксили в очередном обновлении платформы.
impetus
Ок, вот массу таких (и как ниже) подробностей бы сразу в статью — было бы гораздо лучше.
(Соотв., за свой предыдущий коммент — прошу прощения.)
VVizard
все тоже самое можно сказать и о 1С Документооборот, там еще плюсом интеграция с остальными продуктами 1С
Pavel_Gorshkov
На момент выбора платформы (январь-февраль 2016 г.) у 1С Документооборот не было визуального конструктора бизнес-процессов, а для меня это было существенно.
VVizard
На мой взгляд, конструктор БП это игрушка, убедился в этом сам когда реализовывали один из проектов. Со временем схема бизнес процесса все больше усложняется, все больше появляется всяких условий, появляются ситуации когда нужно возвращаться назад или перезапускать процесс, потом выясняется что в разных филиалах разное штатное расписание и разные процессы согласования, при этом они должны корректно работать в общем процессе, и.т.д. и.т.п.
В итоге тот проект мы закрыли и сдали. Но процессный подход применяемый в 1С документоборорт, мне в результат понравился больше и остальные 2 проекта сдавали уже на нем.
При этом 1С: Документооборот тоже настраивается в очень широких пределах: http://v8.1c.ru/doc8/advantages.htm#task
Но есть похожие системы (которые используют конструктор БП), например: http://xn--90afdtkhdeabaxvge.net/process-1s-dokumentooborot.html
В свое время именно их ролики вдохновили заказчика на «гибкий конструктор», а нас на его реализацию.
Pavel_Gorshkov
На мой взгляд, визуальный конструктор БП очень полезная вещь на стадии эксплуатации системы. Как вы верно заметили, в процессе длительной работы пользователей с системой, процессы могут усложняться, т.к. постепенно меняется сам подход пользователей к СЭД. Если раньше пользователи не понимали зачем все это нужно в принципе, то теперь они постоянно приходят с рацпредложениями по оптимизации процессов. Не представляю, как бы мы оперативно вносили необходимые изменения в процессы, если бы не было конструктора.
bot1no4ek
+1
К автору:
Так же хотелось бы видеть больше конкретики, все таки интересно изучить примеры процессов, как автоматизация помогла их улучшить (можно на примере одного) + интересно узнать, а получилось примерно понять, где раньше происходил саботаж работы?
Pavel_Gorshkov
Под саботажем имел ввиду умышленные действия отдельных сотрудников, которые принципиально не хотели работать в системе под предлогом «а зачем мне это, кому надо, тот пусть и работает». К примеру, при запуске системы, отдельные личности пытались согласовывать договорные документы вне системы и передавали проекты договоров на бумаге юристам, которые раньше первыми стояли в листе согласования. Я переговорил с юристами и сказал, чтобы они не принимали распечатанные проекты на согласование и сразу заворачивали исполнителей: «Если хочешь заключить договор — делай через систему, иначе никак».
Pavel_Gorshkov
По улучшению процессов на примере согласования договоров:
Условие:
Число согласующих 7-10 человек в зависимости от вида договора. До 50 договоров в месяц.
Как было:
Исполнитель передавал распечатанный проект договора на согласование и постоянно обзванивал подразделения в поисках переданного на согласование договора. Иногда проекты терялись и приходилось повторять процедуру.
В случае с удаленным филиалом, исполнитель пересылал договор по эл. почте юристам, а они уже распечатывали и передавали дальше.
Как стало:
Исполнитель (в т.ч. сотрудники удаленного филиала) создает карточку договора, заполняет необходимые поля, прикладывает проект договора, нажимает одну кнопку и система автоматически запускает договор на согласование, все маршруты зашиты внутрь и зависят от выбранного вида и типа договора. Если у согласующего есть замечания, проект возвращается исполнителю на доработку. По факту положительного согласования и подписания договора, система автоматически оповещает исполнителя. Исполнитель всегда знает у кого на согласовании договор, не нужно бегать по кабинетам и контролировать ход согласования.
Кроме того сильно экономим время на процедуру за счет параллельного согласования проекта на некоторых этапах.