Контакты
Подписка
МЕНЮ
Контакты
Подписка

Information Security №1/2018: Коммуникации с подразделениями компании

Ekaterina Danilina, 16.03.18

popov

 

 

Автор: Дмитрий Попов, руководитель отдела информационных технологий, ГК "Лето"

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

Коммуникация между подразделениями

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

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

Внутриорганизационные коммуникации

Внутриорганизационные коммуникации должны обладать рядом качеств:

* быть понятными всем получателям;

* сообщаемые сведения должны быть основанными на достоверных фактах;

* давать возможность делегировать поручения и контролировать их исполнение;

* быть непрерывными и простыми в освоении.

Например: внутри компании или группы компаний есть подразделение, которое отвечает за приемку сырья – лаборатория входного контроля, и часто возникают спорные ситуации, которые необходимо обсудить с руководителями других производственных площадок. До внедрения системы ВКС обсуждение происходило в почте с приложением фото, что существенно затягивало процесс и не давало объективной картины проблемы. Развернув систему ВКС, решили проблему общения в реальном времени и демонстрации образцов.

Технология в вакууме не несет ценности

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

Организовать взаимодействие можно десятком сервисов – это и корпоративный портал, и сервисы заявок, подобные Service Desk, и корпоративная почта – перечислять можно еще долго. Смысл в том, что, поставив даже каждый из этих сервисов на рабочее место пользователю, но не рассказав "что это", "почему это" и как применить, пользоваться этим не будут. Компания получит две разные вселенные: в одной существует ИТ-подразделение вместе со всеми инструментами взаимодействия, тут же несколько наиболее технически продвинутых пользователей-энтузиастов; однако основная часть пользователей будет существовать отдельно от всего этого, продолжая мучиться недостатком таких инструментов. Технология сама по себе, существуя отдельно от пользователей, не нужна никому и пользы не приносит. Если служба ИТ как внутренний интегратор делает свою работу хорошо, то после внедрения инструмента она должна обучить конечных пользователей, прописать регламенты взаимодействия, указать бизнес-процессы, в которых необходимо использовать данный инструмент, продолжать культивировать привычку использования до тех пор, пока инструментом не начнут пользоваться в реальной жизни.

У производителей устройств связи существует понятие "эффект количества". Суть этого явления заключается в том, что полезность устройств прямо пропорциональна их количеству. Если у вас одного будет самый крутой телефон на этой планете, то смысла от него не будет. Если телефонов на планете Земля будет два – уже лучше, но пользы все равно немного. А вот когда телефонов миллион – коэффициент полезности совсем другой. Этот принцип хорошо транслировать на внедрение внутренних информационных систем – внедрять технологии внутри компании нужно сразу унифицировано и изменять бизнес-процессы так, чтобы в них участвовали внедренные технологии. То есть если сотрудники будут иметь возможность "делать, как привык", они так и будут делать.

С какими сложностями мы столкнулись и как их преодолели

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


Внедренные инструменты взаимодействия:

* система обмена моментальными сообщениями с указанием статуса занятости пользователя;

* видеоконференцсвязь;

* корпоративный портал;

* использование календарей Microsoft Outlook для личного планирования дня или встреч с возможностью добавления в эти встречи коллег;

* система электронного документооборота.


Если систему ЭДО приняли хорошо, хоть и в процессе эксплуатации было много вопросов, то при попытке внедрить Lync неожиданно получился провал. Для меня стал большим откровением диалог с одним из руководителей отдела, когда на вопрос "Зачем вы отключаете Lync, вместо того, чтобы им пользоваться?" я получил ответ: "Я не хочу, чтобы за мной следили".

То есть пользователь вместо удобства общения с другими отделами или оперативной помощи от ИТ-специалистов видел в этом инструменте только мониторинг присутствия на рабочем месте. По умолчанию Lync меняет статус пользователя при бездействии в несколько минут. И таких пользователей по ГК оказалось много.

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

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

После внедрения мы получили сразу несколько очень весомых плюсов:

* есть точное понимание количества заявок;

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

* количество отработанных заявок и качество выполнения (соблюдение SLA) напрямую влияют на заработную плату сотрудника;

* увидели, что первые три месяца количество заявок росло, потом остановилось примерно на одном уровне.

На сегодняшний день у нас в месяц порядка 250–300 заявок в системе и процент решенных в течение первых двух часов – 63. Здесь же стоит добавить, что внутри ИТ-отдела выстроили и ввели в действие систему ключевых показателей, влияющих на бонусную часть зарплаты, основанную на решении заявок из SD.

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

Итоги

Если попытаться обобщить все промахи, которые были допущены, я бы выделил следующие, главные:

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

* не сделали первоначальное техническое задание с делением на этапы внедрения и оценочные контрольные точки;

* не провели разъяснительные работы с пользователями о преимуществах данных решений;

* не составили регламентирующие документы по взаимодействию с электронными ресурсами;

* не изменили работу, задействовав новые технологии в уже существующих бизнес-процессах.

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

 


Примечание

Лев Палей, начальник отдела ИТ обеспечения защиты информации, АО «СО ЕЭС», редактор рубрики "Управление"

Изменения компании с точки зрения управления процессами обеспечения ИБ

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

* SD – хороший инструмент отслеживания "здоровья" процессов компании с точки зрения ИБ, к примеру уровня знаний по ИБ: путем анализа заявок возможно получить представление о базовой грамотности и определить, с кем требуется провести обучение.

* SD – хороший инструмент формализации операционных процессов – журналирования запросов доступа, предоставления прав в ПО – все это помогает при расследовании инцидентов как ИТ, так и ИБ.

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


 

Читайте также по теме «Управление»:

* Через тернии маркетинга http://www.itsec.ru/imag/insec-6-2016/44

* Как обосновать расходы на ИБ http://www.itsec.ru/imag/insec-1-2017/48

* Об эффективном управлении защитой от киберугроз http://www.itsec.ru/imag/insec-6-2017/28

* В условиях цейтнота http://www.itsec.ru/imag/insec-1-2016/54

Темы:Информационная безопасностьжИБ №1/2018журналУправлениеinformation security

Еще темы...