Смотреть на происходящее во вверенном или соседних подразделениях взглядом руководителя очень важно. Это некоторым образом абстрагированный взгляд, в котором все происходящее обретает форму квадратиков и стрелочек. Для примера я хотел бы рассказать о том, как был произведен «реинжиниринг» одного часто возникающего в любой компании бизнес-процесса – «увольнение» сотрудника, и каковы действия, которые осуществлялись в департаменте ИТ.

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

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

Увольнение сотрудника для ИТ, по логике, должно быть обычной и отлаженной рутинной операцией. Но такие события редко случаются каждый день, и системные администраторы обычно не выделяют времени на регламентирование данного процесса. Обязанность упорядочивания процесса должна ложиться на плечи ИТ-руководителя. А вот волшебная кнопка «Отключить учетные записи во всех системах» остается несбыточной мечтой для любого ИТ-специалиста. СЭД, CRM, ВПН-доступы и ключи, адреса электронной почты и логины, выданные пользователю к различным не взаимосвязанным между собой системам, – вот неполный список мест, где заведены учетные записи.

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

Вроде навести порядок в моменте несложно, но как поддерживать приемлемый уровень порядка на постоянной основе?

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

Чаще всего системный администратор, заблокировав учетную запись в Active Directory, начинает судорожно вспоминать, где еще есть записи и что надо заблокировать.

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

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

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

При создании документа, требующего изменения бизнес-процесса, я следую следующему рецепту:

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

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

3. Создание регламентирующего документа. Оформление на бумаге документа, когда все стало понятно, уже не составляет большого труда.

В нашем случае создаваемый регламент призван описать все необходимые действия ответственных лиц, связанных с процессом отключения или удаления заведенных в ИС учетных записей для увольняющихся из компании сотрудников. Главное – вдумчиво подобрать формулировки и подробно все расписать. Одним из элементов нового документа должен быть словарик с разъяснениями для сокращений, используемых в документе. Лучше всего вынести его в самое начало.

Создаваемый документ лучше всего разбить на 2 части. В первой, текстовой, описываются подробно задействованные системы и выполняемые в них исполнителями действия. Вторая часть – это таблица, в которой приводится так называемый «чек-лист». Она очень полезна при выполнении требований регламента. Таблица просто распечатывается, а в специальном поле исполнитель ставит отметку, выполнив очередной этап. Так можно избавиться от спешки и вероятности, что если отвлекут текучкой, не вернешься к выполнению следующих пунктов.

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

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

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

С точки зрения исполнения, процесс свели к тому, что все операции производятся теперь только одним лицом в рамках контролируемого департаментом ИТ периметра. Это, конечно, потребовало обучения сотрудников работе с различными информационными системами, но и принесло свои плоды. Четкий контроль и выполнение всех технологических операций без делегирования кому-то еще, где могут не сделать или забыть. А еще этот же сотрудник осуществляет контроль исполнения требований регламента для второстепенных учетных записей вне наших систем. До этого никто ни за что не отвечал, каждый ответственный за информационную систему блокировал пользователей так, как считал нужным, ведь все в отделе происходило «неформально», и следов виноватых найти не удавалось.

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

Ну и даже после такого действия все равно возникло несколько интересных особенностей. Например, первоначально не учли, что если не очистить у заблокированной учетной записи в Active Directory поле «Руководитель», то уволенный пользователь будет все еще виден на портале в базе Sharepoint.

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

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

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

Так регламент остается живым и рабочим документом, максимально соответствуя реалиям.

Первоначально поставленная цель – процесс сделать управляемым и контролируемым – была достигнута. Фразы «Не знаю, почему», «Нам никто не сообщил об увольнении…» ушли в прошлое. Все стало прозрачнее, и ИТ-специалисты и другие отделы начали играть по правилам, которые документально закреплены. Все спорные вопросы решаются «языком документов», а не «по понятиям».

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