Самые существенные затруднения в ИТ-отделах связаны с процессами внедрения и трансформации цифровых технологий, нехваткой кадров и обучением сотрудников. Разбираем основные проблемы технических департаментов и рассказываем о путях их решения.
- Введение
- Как выявить сильные и слабые стороны в техническом департаменте?
- С какими трудностями сталкивается технический департамент?
- Самые распространённые проблемы
- Выводы
Введение
Устроить корректную работу технического департамента непросто. Возникают вопросы: как лучше выстроить структуру отдела и производственные процессы? К каким ещё проблемам, в частности — со внедрением, готовиться?
Технический департамент Cloud Networks расскажет о своём опыте: объяснит, как выявить сильные и слабые стороны технического подразделения, опишет трудности, с которыми сталкивается технический департамент, а также разберёт самые распространённые проблемы.
Как выявить сильные и слабые стороны в техническом департаменте?
Перед тем как искать сильные и слабые стороны, нужно в целом понимать, куда вы идёте и каких целей пытается достичь ваша компания. Ведь при отсутствии целей и планов по их достижению вы будете блуждать без пункта назначения и понимания направления.
Поэтому сначала нужно оценить состояние дел:
- Определить стратегические цели бизнеса, планы роста, основные направления.
- Сделать инвентаризацию технических компетенций компании и кадровых ресурсов, процессов, внутренних активов и знаний.
- Оценить текущую и плановую загрузку подразделения.
- Сделать ретроспективный анализ закрытых договоров, проанализировать недочёты и проблемы, выявляемые клиентами при приёмке.
Установленные в компании цели помогут создать описание ключевых задач для их достижения.
Ключевые задачи, как правило, связаны со следующими темами:
- Создание организационной структуры технического департамента.
- Создание и описание производственных процессов компании с последующей автоматизацией.
- Развитие компетенций компании, поиск кадров.
- Формирование системы мотивации технического персонала.
- Создание системы управления техническими знаниями и активами компании.
- Бюджетирование.
При формировании ключевых задач вы сможете найти огромную долю брешей в работе организации и вашего подразделения.
С какими трудностями сталкивается технический департамент?
Ретроспективный анализ закрытых договоров может выявить ряд «бытовых» проблем, с которыми сталкиваются технические подразделения. Наличие брешей в заявленных работах и услугах является нормой на начальных этапах жизни компании и на ранних стадиях развития новых направлений.
Основные проблемы мы разбиваем на две категории: внутренние и внешние.
Внутренние проблемы:
- полное отсутствие специалистов с необходимой квалификацией,
- нехватка человеческих ресурсов.
Внешние проблемы:
- неготовность инфраструктуры клиента,
- отсутствие квалифицированных человеческих ресурсов у заказчика,
- долгие, итерационные согласования,
- изменения ТЗ в ходе реализации проекта.
Разберём самые распространённые проблемы по отдельности.
Самые распространённые проблемы
Проблема: отсутствие конкретики в ТЗ или его изменение в ходе реализации проекта.
Чаще всего в техническом задании не указано конкретное количество площадок размещения оборудования. Зачастую задания составляются в стиле «хотим, чтобы было хорошо». Требования описаны неоднозначно, а от этих параметров зависят стоимость работ и их качество.
- Решение: организация встреч с заказчиком, выяснение всех интересующих исполнителя вопросов и нюансов, а также проведение аудитов и обследований. За несколько часов личного общения с клиентами можно получить больше исходных данных, чем за дни и недели переписки. По итогу общения с заказчиком формируется документ, предшествующий техническому заданию, в котором стороны утверждают чёткое описание задачи: как её видит заказчик и понимает интегратор.
Проблема: клиент не понимает, что именно ему нужно.
- Решение: сформируйте общие вопросы для уточнения потребностей заказчика, чтобы предварительно оценить состояние его ИБ, или проведите аудит ИБ с последующими выводами и рекомендациями. Если задача более-менее понятна, но нет точно сформулированных ожиданий в части функциональности искомой системы, возможно проведение пилотных проектов по потенциальным решениям, чтобы узнать потребности клиента непосредственно на его площадке. Показ различных решений и их функциональных возможностей может быть весьма полезен. Мы в Cloud Networks даём заказчику выбор и получаем примерную конфигурацию «боевого» решения, сокращая сроки выполнения работ.
Проблема: неадекватные сроки внедрения, потому что СЗИ нужно было внедрить «ещё вчера».
- Решение: казалось бы, самое очевидное — подключить все имеющиеся ресурсы и всех доступных сотрудников в пользу срочного проекта. Но по итогу мы вместо одного срочного проекта с отставанием по срокам получим несколько.
Наш подход к таким задачам выглядит следующим образом:
- Если задача звучит как «нужно было сделать ещё вчера», то мы определяем, что именно требуется заказчику. Скорее всего, есть небольшая составляющая всего проекта, которая является критической для полноценного функционирования бизнеса.
- Определяем, возможно ли критическую часть задачи разделить по объёму. Например, если «необходимо срочно внедрить 10 кластеров межсетевых экранов на 10 площадках заказчика», то, скорее всего, заказчику критически важно внедрить по кластеру МЭ на паре основных площадок, а потом уже — на всех остальных. В таком случае мы можем не внедрять сразу всё, а действовать в рамках календарного плана внедрения по площадкам. Для оперативности внедрения мы можем предложить сформировать не полный комплект документации, а краткое техническое описание, где будут описаны и утверждены схема и конфигурация внедряемого решения. Полный комплект проектной документации будет разрабатываться параллельно. Можно сказать, что это — применение методики «эджайл», только не в разработке ПО, а в ИБ.
- Во внутренней кухне мы оцениваем статусы наших проектов и то, на каких этапах они находятся. Если у инженеров по другим проектам есть какие-то паузы, связанные с согласованием работ или документации, мы можем временно подключить таких инженеров для выполнения критической части срочного проекта.
- В итоге мы формируем удобный для всех сторон календарный план проектирования и внедрения, учитывающий критические для заказчика точки.
Проблема: неготовность инфраструктуры заказчика ко внедрению СЗИ.
При внедрении средств защиты необходимо подготовить имеющуюся инфраструктуру (изменить топологию сети, привести её в порядок, выделить новые подсети или «причесать» свою сеть), а также определить порты подключения к сетевому оборудованию или подготовить виртуальные ресурсы, места размещения оборудования, обеспечить достаточность ресурсов электропитания и систем кондиционирования и т. д.
Перед началом работ рекомендуем согласовывать всё с тем, кто отвечает за безопасность. Как правило, вся подготовка выполняется во время начала работ по внедрению, что увеличивает сроки их выполнения. Причин тому несколько: недостаток компетенций и свободного времени у представителей ИТ-службы, полное отсутствие заинтересованности ИТ-службы во внедрении средств защиты информации.
- Решение: «прокачать» свои навыки и компетенции по системам и решениям, которые косвенно взаимодействуют со внедряемыми продуктами. Важно, чтобы служба безопасности обозначила чёткие требования к ИТ-службе на самых ранних этапах проекта. Один из возможных вариантов — предоставить ИТ- и ИБ-службам заказчика предварительный список требований к инфраструктуре, определённый на этапе предпроектного обследования или аудита. Этот список можно изобразить в виде презентации, где нужно отразить важность требований, невыполнение которых может сильно повлиять на сроки реализации проекта.
Выводы
В статье мы раскрыли слабые и сильные стороны технического департамента, а также рассказали, как решить актуальные проблемы отдела. Надеемся, что наши советы помогут и вам в настройке его правильной работы!
Напоследок отмечу, что подобрать решения, спроектировать архитектуру и внедрить продукты вам помогут партнёры-интеграторы, такие как Cloud Networks.
