Ekaterina Danilina, 16.03.18
Автор: Дмитрий Попов, руководитель отдела информационных технологий, ГК "Лето"
Сегодня, когда все вокруг только и говорят о приходе четвертой индустриальной революции, Интернет вещей проникает всюду: мусорные баки сами отчитываются о заполняемости, датчики на полях – оценивают рост зерновых культур. Свежеиспеченные организации по контролю и стандартизации 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
