Добрый день. Хочу поделиться своим опытом внедрения 1С: Документооборот (далее - ДО) в нашей организации. Показать как мы использовали функционал ДО для автоматизации кадровых процессов, а также показать разработку нашего программиста в ДО: табель учета рабочего времени. Статья состоит из трех частей: первая часть касается собственно всех кадровых документов, которые настраивали в пользовательском режиме, и опыт запуска и обучения пользователей, вторая часть - описание разработки программиста, третья часть - доработки, которые были сделаны в ДО для повышения эффективности работы пользователей.
Организация у нас состоит из головного офиса и примерно ста обособленных подразделений (ОП) по всей стране. Деятельность организации: опт и розница. В ОП есть свой штат сотрудников, кадровый документооборот состоит из полного набора документов: начиная от приемов, отпусков, и заканчивая табелем учета рабочего времени. В ОП все документы согласовывают с головным офисом, бумажный документооборот ведется через почтовые службы. Вся работа по согласованию кадровых документов ведется в корпоративном чате с форумом.
Chapter One. Анализ кадровых процессов, перенос их в ДО
В начале 2019 года, в нашей организации было принято решение о внедрении ДО. Программистами были произведены основные настройки ДО, заведены пользователи и другие необходимые настройки. Затем от отдела кадров пришло ТЗ, которое состояло из фразы "перенести работу, по всем кадровым документам, из корпоративного чата в ДО" и перечень документов:
- Прием
- Увольнение
- Больничные листы
- Отпуска
- Командировки
- Выдачи копии трудовой книжки
- Заявление на смену фамилии
- Уведомления на отпуска
- Табель учета рабочего времени.
Начала с документа приема. Проанализировала весь процесс, т.е. как он проходил в "живом виде", определила кто какие задачи выполняет, определила основных согласующих и условия их появления в процессе и т.д. В итоге получила из хаоса четкую и понятную структуру бизнес-процесса: кто что и когда.
Схема процесса приема (чтоб наглядно увидеть "масштабы" процесса):
Данный бизнес-процесс в течение года оптимизировался и уменьшался.
Краткое описание процесса приема:
1. Руководитель ОП (или эйчар) создает заявку на прием, указывает всю необходимую информацию, вкладывает все необходимые файлы для оформления приема и запускает заявку в работу.
2. Запускается основное согласование заявки, в котором участвуют те или иные руководители подразделений, ответственные за приём сотрудники.
3. Если прием согласован, то сотруднику отдела кадров приходит задача оформить сотрудника, после чего запускаются задачи на исполнение, ознакомление.
4. Задачи на исполнение приходят в ИТ-отдел, чтоб завели сотрудника в базах, в админский отдел, чтоб завели доменку, почту и др. В расчетный отдел приходит задача, чтоб завели сотруднику его расчетный счет.
5. На ознакомление: задачи приходят в отдел труда, отделу по персоналу и другим отделам.
В таком виде схема заявки на прием очень проста и понятна. С условиями маршрутизации она существенно увеличивается, т.к. например, задача на заведение учетной записи, в базах 1С, приходит по определенным должностям. Задача на доменку, почту, тоже с учетом должности принимаемого сотрудника, т.е. каждый сотрудник получает только ту задачу, которая предназначена ему. Так же вложения при приёме видят только те сотрудники, которые имеют право это видеть.
Сейчас, когда вижу, на сколько этот процесс прост и понятен - улыбаюсь. Но тогда, на запуск первой заявки на прием у меня ушло полтора месяца: от исследования процесса до обучения пользователей. На этом же документе, наши пользователи начали знакомиться с ДО, благо прием сотрудника затрагивал очень много подразделений.
Опишу краткое содержание других документов.
Увольнение:
1. Сотрудник или руководитель сотрудника запускает заявку на увольнение, вкладывает скан заявления.
2. Запускается согласование обходного листа.
3. После исполнения отделом кадров задачи по оформлению увольнения, запускается пул задач на исполнение и ознакомление.
4. ИТ-отделу приходит задача на исполнение по закрытию всех учетных записей сотрудника.
5. Сотрудникам других отделов приходят задачи на ознакомление с увольнением сотрудника.
Отпуск:
1. Сотрудник запускает заявку на отпуск, вкладывает скан заявления
2. Заявка идет на согласование, затем приходит в отдел кадров.
3. Отдел кадров вкладывает скан приказа, оформляет отпуск в ЗУП.
4. Сотрудник получается скан приказа, распечатывает его, подписывает и отправляет оригиналы в отдел кадров.
Больничный лист:
1. Сотрудник указывает номер б/л, или если это "синий" б/л вкладывает скан.
2. Сотрудник ОК получает задачу на исполнение, оформляет б/л.
3. Расчетный отдел получает задачу на расчет б/л.
p.s..: на тот момент в нашей организации не было загрузки б/л напрямую в ЗУП.
У остальных документов схема примерно такая же: согласование, задача сотруднику ОК на оформление в ЗУПе, исполнения, ознакомления.
За полгода запустили все документы.
Самым трудозатратным оказалось собрать информацию по бизнес-процессу, так как, от отдела кадров, в качестве ТЗ я получила только наименование документов для проекта. Не было указано ни ФИО участников процесса, ни их обязанности в этом процессе, ни условий их появлений. Я обзванивала каждого участника и выспрашивала его работу по тому или иному документу. А после того как запускала документ, могли всплыть неизвестные ранее нюансы, и маршрут и документ дорабатывался "по живому". Вы скажите, почему не описывала это всё сперва на бумаге, отвечу: бизнесу нужно было здесь и сейчас, "писаниной" времени заниматься не было. Инструкции писала после того как документ стабильно работал недели две три.
Второй сложностью было обучение пользователей. Хотя я это сложностью не считаю, просто это обучение занимало очень много времени. Я была и консультантом и тем человеком, который параллельно создает и настраивает следующий документ и при этом отвечает на звонки пользователей. Технические вопросы по настройке документа и маршрута к нему, особых сложностей не вызывало. Я использовала только табличную схему настройки процессов, обмены с ЗУП программист настроил, и в документах мы уже оперировали актуальными данными. Если мне необходимы были какие-нибудь доработки, писала техническое задание и программисты оперативно допиливали функционал ДО (печатные формы, заполнение реквизитов и др).
В итоге за полгода организация получила читабельные схемы своих кадровых процессов. Стало понятно кто чем занимается, ушли от личных чатов, общению через почту, от корпоративного форума. Снизили трудозатраты, повысили качество выполняемых работ. А ДО зарекомендовала себя как программа которая помогает наводить порядок в рабочих процессах.
Параллельно с моими наработками, программист начал настраивать обмен между ДО и ЗУП. Тем самым "убили двух зайцев":
- У меня во всех кадровых документах в ДО появилась возможность выбирать сотрудников, получать актуальную кадровую информацию по ним.
- Использование кадровой информации для подсистемы табеля учета рабочего времени.
Chapter Two. Табель учета рабочего времени
Табель учета рабочего времени (далее просто табель) в нашей организации согласовывался в формате Excel. Я думаю описывать как это происходило в "живом" не обязательно и так понятно. Одновременно с переводом согласования кадровых процессов в ДО, было принято решение о разработке табеля в ДО.
Требуемый функционал от заказчика:
1. Вести табель в удобном табличном виде.
2. Табель должен иметь возможность на автоматическое закрытие периода (после 15 числа, и после 30/31 числа).
3. Табель должен согласовываться по стандартным механизмам ДО.
4. В табеле должны отображаться все отклонения от рабочего времени сотрудника из ЗУП.
5. Заполнение табеля должно быть автоматическим при выборе подразделения.
6. Возможность гибкой настройки доступа к табелю и др.
7. Должен поддерживаться учет по различным графикам, а так же необходимо учитывать время обеда.
8. Связь с программным обеспечением, установленным на проходной, и заполнение табеля согласно этим данным.
У нашего разработчика ушел примерно один месяц на разработку табеля и настройки обмена с ЗУП (у нас было несколько баз ЗУП). Еще один месяц ушел на тестирование и доработку механизма. В итоге мы получили очень удобный инструмент.
Вот так выглядит сам документ:
Вы указываете подразделение и табель заполняется списком сотрудников этого подразделения. Если в ЗУПе были введены отпуска, больничные и другие документы по сотруднику, то в ДО эти все отклонения заполняются. Но, если чего-то нет, то в табеле это можно заполнить самому. После заполнения документа, табель отправляется на согласование. В маршруте указан руководитель подразделения, затем отдел кадров. После согласования всеми табель закрывается на изменение, в зависимости от даты. То есть, если это табель на аванс, то период с 1-15 для изменения закрыт, и пользователь может изменять данные после 15 числа. Соответственно табель полностью закрывается на редактирование после 30/31 числа если он согласован отделом кадров.
Есть возможность просматривать и заполнять табель в нескольких режимах:
Всего было разработано пять режимов для просмотра и заполнения табеля.
Так же есть возможность вести учет переработок, указывать часы смен, обеды и перерывы в сменах и т.д.
Итог внедрения подсистемы по учету рабочего времени:
1. Ушли от подачи табелей в Excel, что подразумевало под собой множество различных действий.
2. Единый механизм для всей организации.
3. Удобство заполнения, удобство в отправке.
4. Повышение контроля.
5. Благодаря запуску табеля через ДО, вся организация разом начала работать в ДО, т.к. табель сдают все отделы.
Chapter 3. Какие доработки мы произвели в ДО:
1. Доработка, которая позволяет при отказе в согласовании вернуть задачу тому кто отказал, а не начинать согласование с начала.
2. Запрет запуска процессов не по шаблону документа, в том числе, мы сделали недоступным для пользователей выбор стандартных маршрутов (ознакомление, исполнение и др).
3. Вывели историю выполнения процессов в рамках комплексного процесса, каждого подпроцесса в описании задачи для определенных пользователей.
4. Контроль за вложением определенных видов файлов (т.е. допустим для того, чтоб запустить договор, пользователь должен обязательно вложить 5 файлов: ИНН, Устав, Решение о назначении директора и т.д.).
5. Убрали кнопку "Согласовано с замечаниями".
6. В процессе согласования, сделана настройка, чтоб указывать пользователя, чей отказ в согласовании не повлияет на результат. Это было сделано из-за того, что есть пользователи, которые должны быть в согласовании, но их не согласование не должно возвращать задачу пользователя, т.к. права отказа в согласовании у него нет.
Если какая-либо из этих доработок настраивается типовыми средствами, буду рада узнать как это делается. К сожалению, времени разбирать типовой ДО и его возможности не было =).
p.s. На данный момент я в этой организации уже не работаю, но все мои наработки и разработки программистов используются. Когда пересекаюсь с сотрудниками с отдела кадров слышу только благодарности за внедрение этого проекта. И это очень приятно. ДО в этой организации всё больше и больше начинают использовать для автоматизации своих "бумажных" процессов. Для себя лично сделала такое наблюдение: ДО начинают "любить" спустя два года от начала внедрения, так как за два года становится пользователям понятно, какой хороший инструмент у них есть, чтоб автоматизировать и регламентировать свои процессы.
В демо-версии ДО оказывается тоже есть кадровые документы в каком-то первоначальном виде и это говорит о том, что ДО очень удобно использовать для организации этого вида учета. При этом, у всех он будет почти одинаков, так как из-за ЗУПа у всех кадровые процессы проходят однообразно.
Заранее хочу поблагодарить читателей, а так же тех, кто будет писать свои комментарии о своём опыте внедрения аналогичных процессов.
