Как продать ИБ. Практическое руководство.

Как продать ИБ. Практическое руководство.
Как показывает практика, очень тяжело убедить руководителя потратить деньги на то, что ему сейчас не нужно

Слово должно быть верным, 
действие должно быть решительным.
Конфуций Кун-цзы

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

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

Как показывает практика, очень тяжело убедить руководителя потратить деньги на то, что ему сейчас не нужно. Следует также помнить, что ИТ-бюджеты в российских компаниях крайне низкие (по сравнению с западными) и имеют тенденцию к дальнейшему сокращению. Обычно ИБ становится частью бюджета ИТ, соответственно, данная статья расходов для первых лиц не является приоритетной.

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

Как же все-таки увеличить шанс и с высокой вероятностью получить необходимый бюджет на ИБ (конечно, если у вас нет возможности испугать руководителя до такой степени, что ему станет это интересно)? Давайте вместе попробуем построить простую логическую схему. Возможно, именно ее элементы позволят вам найти правильный подход к руководителю и обоснованию бюджета.
Перед построением логической цепочки хочу обратить ваше внимание на очень важную вещь, которую нужно понимать и постоянно держать в голове при общении с «топами». 

Психология CEO основана на элементах ре-активного управления. Как правило, это управление по отклонениям. При выявлении проблемы идет команда, что необходимо сделать для ее устранения. Психология же CIO основана на элементах про-активного управления. Это использование потенциальных возможностей. Мы видим технические возможности и можем предложить их для устранения вероятных проблем в будущем. Это несоответствие и есть основная проблема «разных языков» CIO и CEO, блокирующая принятие как ИТ-, так и ИБ-бюджетов.

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

Найти проблему (что продать)

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

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

Найти владельца проблемы (кому продать)

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

Здесь необходимо четко понимать, что ИТ-директор не должен быть ответственным за эту проблему и не должен быть ее владельцем. Очень часто руководители других подразделений свои проблемы стараются переключить на ИТ-блок. А дальше — как в анекдоте: сам придумаешь, сам решишь, а потом сам себя накажешь. Если вы не садомазохист — это не ваш путь.

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

Составить план мероприятий (как продать)

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

Пример. Провести аудит по ИБ, на основании которого составить план работ по отключению социальных сетей и мессенджеров, параллельно решить больной вопрос соответствия организации требованиям ФЗ-152 «О защите персональных данных». Прописать в регламенте правила подключения к сетевым ресурсам и, наконец, определить, есть ли в организации коммерческая тайна и где она прячется физически.

Оценка вероятности и информирование о рисках (как обосновать)

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

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

Только не перегибайте палку, не нужно из анализа делать «пугалку» — этого не любят. Анализ должен не напугать руководителя, а пояснять причины, почему выгоднее сейчас сделать так и потратить деньги, чем потом разгребать возможные последствия проблемы. 

Инициирование проблемы (информирование руководства)

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

Пример. Руководитель отдела продаж на отчетном совещании у руководства, объясняя причину невыполнения планов, может назвать проблему и попросить ИТ-директора подумать, каким образом ее можно решить технически.

Снять сопротивление (очистка дороги)

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

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

Защита бюджета (получение ресурсов)

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

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

Опубликовано 30.09.2013

Похожие статьи