Как часто вы обнаруживаете неизвестные вам элементы в ИТ-инфраструктуре вашего предприятия? Или как часто на первую линию поддержки приходят обращения по ИТ-услугам, по которым отсутствует информация?
Кристофер Рентроп, профессор университета прикладных наук города Констанц, имеет на этот счёт своё мнение:
Теневые ИТ – известный феномен в современной бизнес-среде. Бизнес-подразделения самостоятельно проектируют, разрабатывают и обслуживают системы для поддержки своих процессов. Несмотря на то, что теневые ИТ поддерживают критически важные бизнес-функции и, следовательно, способствуют появлению множества рисков, они по-прежнему не запрещены. Из-за этого существует потребность в управлении теневыми ИТ. Так как COBIT 5 является мощным фреймворком для управления ИТ, интересно посмотреть на то, как COBIT может помочь в управлении теневыми ИТ.
Кристофер подготовил вопросы в статье на портале международной профессиональной ассоциации ISACA, которые действительно заставляют задуматься:
- Какие процессы COBIT предназначены для организаций с образовавшимися теневыми ИТ?
- Какие процессы COBIT отсутствуют или недостаточно зрелы, раз бизнес подразделения сами осуществляют поддержку своего ИТ-обеспечения?
- Как кто-то может инициировать действия по выявлению теневых ИТ?
Ответы на эти вопросы от Кристофера приведены ниже.
Первый вопрос касается зрелости ИТ в целом. В COBIT 5 существует несколько процессов, которые касаются общей целостности и эффективности ИТ в компании. Управление рисками и соответствие требованиям и архитектура предприятия – это те темы, для которых требуется целостный взгляд на ИТ. Существование теневых ИТ препятствуют формированию целостного представления, а значит эти важные функции нарушены.
Например, в случае управления рисками, такие процессы, как EDM03 и APO12, требуют определения предрасположенности к риску и области проявления рисков. Кроме того, все соответствующие риски должны быть известны для осуществления контроля над ними. Но по своей природе теневые ИТ являются сложно контролируемыми. В наших исследованиях мы никогда не видели рисков отмеченных нашими заказчиками, которые были бы сопряжены с теневыми ИТ. При этом более чем в 16% всех случаев теневая ИТ-система была критически важной для процессов с приемлемым временем восстановления менее одного дня.
Аналогичную ситуацию мы можем наблюдать в управлении соответствием ИТ требованиям внутренних и внешних регуляторов: существующие европейские требования GDPR могут быть нарушены теневыми ИТ, поскольку может быть нарушена цель обработки данных, которая была согласована с клиентом. Кроме того, о теневых ИТ часто нет информации, поэтому компания не может отчитываться обо всех системах, обрабатывающих персональные данные. Наконец, в теневых системах часто отсутствует нужное техническое обеспечение, которое обеспечивает контроль доступа и удаления данных.
Что касается общей архитектуры предприятия, то теневые ИТ также могут стать препятствием для успешного управления системами компании и технологическим ландшафтом.
Поскольку теневые ИТ-системы часто неизвестны внутри компании, то сведения об их архитектуре, компонентах и структуре данных являются неполными, и поэтому такие процессы, как APO01 и APO03 могут выполняться неполноценно. Кроме того, такие процессы, как EDM04 игнорируются, так как утверждённые принципы для построения архитектуры могут не соблюдаться.
Второй вопрос касается качества конкретных теневых ИТ-систем. При оценке существующих экземпляров теневых ИТ важно понимать качество текущего управления ими. Помимо этого, COBIT 5 предлагает хорошую стартовую точку для этой задачи: несколько процессов имеют дело с конкретными ИТ-услугами и могут быть использованы для оценки качества каждого отдельно взятого экземпляра. Как и следовало ожидать, бизнес подразделениям не хватает профессионализма в вопросах управления ИТ, поэтому они игнорируют важные процессы из доменов BAI и DSS. Чаще всего такие задачи, как управление затратами, планирование, тестирование и безопасность услуг не продумываются. Например, идентификация пользователей обычно не существует в теневых ИТ-системах, а значит и процесс DSS05.04 не выполняется. Ниже представлены примеры отсутствующих процессов из практики автора.
Наш третий вопрос касается обоснования и запуска инициативы по выявлению теневых ИТ. Как объяснялось выше, теневые ИТ влияют на общее качество управления ИТ за счёт своего низкого качества. Это оправдывает запуск инициативы по выявлению теневых ИТ, иначе они несут неуправляемые риски для компании. При выполнении процессов BAI10.05 и DSS04.04 ИТ-аудитор может пресечь возникновение теневых ИТ.
Инициатива должна быть направлена на выявление и оценку всех существующих экземпляров теневого ИТ, а также определение мер по смягчению существующих рисков. Например, такие меры могут включать передачу ответственности за теневую ИТ-услугу в ИТ-подразделение или определение стандартов качества для бизнес-подразделений. Помимо идентификации существующих экземпляров теневых ИТ, такая инициатива также помогает выявить недостатки существующей системы руководства ИТ.
Теневые ИТ могут быть темой, представляющей крайнюю важность. Поэтому рекомендуется придерживаться некоторых хороших практик: простая рассылка опросников для составления списка экземпляров теневых ИТ даёт свои плоды. Идентификация теневых ИТ путем прямых интервью обычно более успешна, но может занять больше времени. Таким образом, рекомендуется провести пилотные проекты с целью приобретения знаний и опыта о теневых ИТ-системах в рамках организации. Так бизнес-подразделения смогут идентифицировать и проанализировать наличие теневых ИТ-систем самостоятельно и дать им оценку. Эта самооценка должна быть встроена в адаптивную структуру руководства ИТ, которая на гибкой основе распределяет обязанности между бизнес- и ИТ-подразделениями. Функция ИТ-аудита должна взять на себя роль посредника, чтобы проблема теневых ИТ была разрешена. После встраивания ИТ-аудиторам следует верифицировать качество выбранного подхода к самооценке и качество работы адаптивной системы руководства ИТ.
Опросники неэфективны для выявления “теневых” услуг.
Используя первую линию, внедрили процесс их выявления построенный на следующем:
Зарегистрировали услугу “Неопределенная” и в случае если первая линия (только принимающая и регистрирующая заявки) сомневалась на какую услугу её относить – ставили эту услугу. Специалистов обязали при закрытии отвечать за корректность указания услуги в этом поле (естественно аудит за этим вели активный + контроль за трудозатратами всех специалистов).
Выявили около 30 “новых” услуг и время от времени вылавливаем новые услуги востребованные бизнесом тут же оформляя по ним соглашения и легализуя их переводя из Неопределенных в номинальные.
Очень полезный механизм – при выводе подразделений (не только ИТ) в аутсорсинг.