Как СКУД внедрить и корпоративной культуре не навредить

Время и деньги большей частью взаимозаменяемы.
Уинстон Черчилль
Жизнь отнимает у людей слишком много времени.
Станислав Ежи Лец

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

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

Тема корректной постановки задач при реализации ИТ-проекта не раз поднималась в профильных изданиях, но то, что в теории выглядит логично, на практике часто приобретает формы иррациональные. На вопрос, каким образом обойти «острые углы» и максимально четко выстроить процесс внедрения ИТ-решения, однозначного ответа нет: все очень индивидуально. Попробуем выделить основные моменты внедрения системы учета и контроля доступа (СКУД) на примере системного интегратора РАМЭК.

Два года назад перед ИТ-департаментом компании встала задача внедрения системы контроля и учета доступа. Компания активно развивалась, значительно выросло количество сотрудников.

РАМЭК является собственником здания в Санкт-Петербурге общей площадью 3 287 м² с офисными, производственными и складскими помещениями. Общая численность сотрудников на конец 2007 г. составляла 412 человек, на конец 2008 г. — 600.

«Первичная бизнес-задача, поставленная руководством компании перед службой ИТ и службой персонала, звучала так: наладить учет рабочего времени сотрудников, — отмечает Александра Осьминина, заместитель генерального директора по персоналу и социальным вопросам группы РАМЭК. — Говоря простыми словами, необходимо было обеспечить понимание реальной ситуации: если сотрудники часто отсутствуют, то всегда ли по производственным причинам, а если по личным, то в разумных ли пределах? Несмотря на то что компания всегда лояльно относилась к личным потребностям персонала, от отработки „положенного времени“ зависела эффективность предприятия.

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

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

При реализации проекта служба персонала в первую очередь должна была максимально позитивно позиционировать учет времени сотрудникам и не нарушить атмосферу уважения к человеку и взаимного доверия, которые были (и есть) в компании. Требовалось максимально возможно упростить процедуры, реализация которых была ей поручена. Также служба персонала выставила к системе ряд требований: гибкость, возможность внесения корректив и возможность вариативности различных отчетов, в частности в исследовательских целях.

Службе ИТ требовалось максимальное участие всех сторон в реализации проекта и его „обкатке“».

«Первым нашим шагом, конечно, стал анализ рынка поставщиков СКУД, который показал, что на тот момент решений, которые полностью удовлетворяли наши потребности, не существует, — рассказывает Александр Коротов, начальник ИТ-отдела группы РАМЭК. — Оказалось, что выбор невелик: можно было воспользоваться либо самописными системами, либо „коробочными“ решениями, которые не подходили под корпоративную информационную систему (КИС) компании, либо отдельными HR-модулями, соответствующими „заводскому“ принципу работы, что тоже не отвечало поставленным задачам.

Системы же, покрывающие почти весь необходимый функционал и подходящие под АСУ РАМЭК, стоили неоправданно дорого.

Вследствие этого было принято решение разработать программное обеспечение собственными силами. Группа программистов, состоящая из штатных сотрудников РАМЭК, взялась за создание ПО с автоматическим экспортом данных из СКУД в КИС компании, модулем ввода зачтенных отсутствий (личная причина, местная командировка*, длительная командировка (более одного рабочего дня), больничный лист, очередной отпуск, неоплачиваемый отпуск, отгул, повышение квалификации, неявка, ошибка).

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

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

Идеология, как и все последующие регламенты, разрабатывалась вместе со службой персонала. Основным отличием системы от „заводской“, где 90% присутствий на рабочем месте закладывается строго „от и до“, должна была стать возможность гибко учитывать специфику работы не только каждого подразделения в частности, но и адаптироваться под конкретных сотрудников.

Кадровый состав поделили на 4 основные группы. В группу А вошли сотрудники с четко зафиксированным рабочим временем в офисе (например, с 9:00 до 18:00 или с 10:30 до 19:30). В группу вошли диспетчеры и другие сотрудники, чье присутствие на рабочем месте принципиально. Средняя продолжительность рабочего дня при этом должна составлять 9 часов.

Для сотрудников группы В, в которую вошли, например, работники бухгалтерии, установили относительную свободу в определении начала и окончания рабочего дня. Например, начало рабочего дня с 9:00 до 10:30, окончание — не раньше 18:00. Несмотря на то что возможны и иные варианты, условие 9 часов в день также должно выполняться. Т. е. если в какой-то день сотрудники присутствуют на рабочем месте 7 часов, то в будущем они должны отработать 11. Работу за пределами офиса данная группа планирует самостоятельно, предупреждая об этом непосредственного руководителя.

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

Монтажники, наладчики и другой персонал, работающий вне офиса, составили группу D.

Помимо основных групп были выделены подгруппы. Например, подгруппа „Ресепшен“ получила свой алгоритм присутствия на рабочем месте: в течение установленного интервала времени на территории обязан присутствовать хотя бы один сотрудник. Данный порядок позволяет оперативно отвечать на входящие сообщения, встречать гостей компании и т. д., не „привязывая“ жестко к рабочему месту всех сотрудников секретариата одновременно.

Система разрабатывалась и внедрялась в общей сложности около года.

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

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

Теперь данные о входе/выходе каждого сотрудника попадали в систему СКУД в режиме реального времени по цепочке: считыватель ® контроллер (контроллеры способны работать автономно и помнят до 1 тыс. событий) ® управляющий сервер.

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

„Личные причины“, „местная командировка“, „длительная командировка“ и „повышение квалификации“ отмечались в программе сотрудниками самостоятельно. Остальные причины отмечались на основе данных, полученных от инспектора отдела кадров.

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

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

Система также позволяла формировать руководителям или уполномоченным сотрудникам отдела персонала отчеты по группе или по одному сотруднику в интерактивном режиме.

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

«Разъяснить сотрудникам, что система контроля и учета доступа внедряется не столько для того, чтобы следить за ними, сколько для регламентации и оптимизации рабочего времени, — задача нетривиальная, — замечает Александра Осьминина. — Не стала исключением и компания РАМЭК: поначалу люди психологически не хотели принимать изменения.

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

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

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

Также система дает возможность:

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

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

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

Сегодня система успешно работает и полностью отвечает изначально поставленным задачам. Поскольку данная СКУД разрабатывалась индивидуально под потребности РАМЭК, она имеет четкую корреляцию с организационной структурой и гибко масштабируема, что сводит затраты на ее поддержку и развитие к минимуму».

Об авторах:
Александра Осьминина — заместитель генерального директора по персоналу и социальным вопросам группы РАМЭК;
Александр Коротов — начальник ИТ-отдела группы РАМЭК.

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