×
Сколково и InfoWatch. КИБЕРБАТАЛИИ. ВЕБИНАР № 1: Приоритеты компетенций в Hi Tech проектах: кого винить в провале?

Сколково и Ifowatch: Серия бесплатных Вебинаров по Информационной безопасности c 29 июня по 17 августа.

 

Интересы заказчика представляет Мария Воронова, ведущий эксперт по информационной безопасности InfoWatch.

 

Интересы исполнителя от команды внедрения – Юрий Савилов, инженер внедрения InfoWatch.

 

Модератор: Олег Седов, главный редактор BISA.

 

Совместный проект Фонда «Сколково» и ГК InfoWatch - «Кибербаталии», - стартовали 29 июня.

 

Проект проходит в формате интерактивных talk show с участниками IT-кластера «Сколково» и завершится 17 августа.

 

Конкурирующие вендоры и сотрудники различных бизнес-подразделений внутри одной компании впервые сойдутся для открытых дискуссий по наиболее острым вопросам в сфере информационной безопасности.

 

Партнерами проекта выступают ассоциация BISAJSON.TV, компания Крибрум и холдинг Анкор.

 

Расписание Кибербаталий

 

Смотрите видео по этой ссылке

 

 

Читайте полную расшифровку «Кибербаталии»:

 

 

Олег Седов: Всем привет, мы сегодня начинаем наши кибербаталии. Сегодня пилотный, тестовый проект, на который мы выставили тему: "Приоритеты компетенций Hi-tech проектах. Кого винить в неудачах?" Дело в том, что актуальность этой темы объяснить очень легко, я уже много раз говорил в своих статьях, публикациях, что я считаю, решений в области IT и ИБ на рынке скверных, в общем-то, нет. Ну, посудите сами, просто никто не будет заниматься плохими решениями, потому что это деньги, это время, это компетенции, это люди, сотрудники и какие-то настроения и ожидания. С другой стороны у нас множество примеров, когда достойные решения внедрялись, ну скажем так, кривыми руками.

 

Сейчас сложность проекта такова, что за каждым внедрением должны быть какие-то подтвержденные компетенции, поэтому говорить, что проблема на той либо на другой стороне, либо только на той, либо только на другой, наверное, нельзя. Это какой-то общее непонимание масштаба проблематики, которую сегодня хотелось обсудить. И прежде чем к этому перейти, буквально два слова о нашей ассоциацией BISA, которая объединяет специалистов в области информационной безопасности, блоги, интервью, дискуссии, живое общение, журнал «безопасность деловой информации», конференции BISA-саммит, который в этом году состоится 23 сентября в Москве, где мы уже анонсировали, будет проведено финальное награждение победителей наших кибербаталий. Итак, первый вопрос, коллеги, в ИБ проектах одновременно дешево, качественно и быстро не бывает. За все надо платить, казалось бы, вещи очевидные, но при экономии теряется качество. Можно ли так расставить приоритеты при внедрении, чтобы не разочароваться в результате. Первая Мария Воронова.

 

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

 

Этот портфель проектов, сформированный, мы в свое время показывали большому количеству исполнителей из числа интеграторов тех или иных решений, и просили оценить. Вот ни один из интеграторов не пошел копать глубже, не спросил, нужно ли нам это на самом деле, не узнал о приоритетах, о возможных сроках, о текущей ситуации, а проекты были просто оценены и так как обращались к большому количеству исполнителей, стоимость также разнилась, примерно на 70% от минимума и максимуму, которые нам предложили. А мне же не нужен Мерседес по цене Жигулей, это было бы перебором, но в тоже время, оплачивая Toyota Camry вместо этого получать Жигули. Я сейчас говорю про качество. Юрий, есть что ответить?

 

Юрий Савилов: Конечно, Мария, добрый день. Я сегодня представляю сторону подрядчика, то есть тех людей, которые делают все возможное, чтобы заказчик был удовлетворен и чтобы не раскидывался такими громкими заявлениями, что мне не нужны Жигули по цене Мерседеса. В первую очередь заказчик сам должен понимать, что он хочет, что есть на рынке, что существует, что дешево, что быстро, что качественно и прочие нюансы. Любой заказчик в первую очередь должен обратиться к вот этой диаграмме, которую вы видите на своих экранах. Я думаю, каждый из вас ее видел и прекрасно знает, что эта диаграмма отображает действительность. На самом деле можно получить все эти три качества вместе, но опять же здесь зависит от тех критериев, по которым производится оценка, например, обычно серьезный проект вовлекает внутрь себя множество звеньев, которые друг с другом взаимодействуют. Это ИБ, IT, бизнес, прочие персоны, люди, отделы, сторонние организации.

 

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

 

Мария Воронова: Такой вопрос. То есть вы понимаете, что быстро, дешево и качественно, вы готовы такие проекты делать, но при этом всем есть понимание, что это для галочки и решение не будет использоваться, а будет стоять в стороне. Ты сам об этом только что сказал. Зачем он тогда вообще нужен? Зачем на него тратить деньги?

 

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

 

Олег Седов:Коллеги, я бы хотел заметить одно. За последние 10-15 лет на российском рынке накоплен огромный опыт ведения самых различных проектов, то есть это уже действительно выросло поколение, целая культура проектных менеджеров, которые на первых стадиях проектов понимает, каков это проект. Сейчас, конечно же, вы лукавите, говорите о тех проектах, которые вам выгодно представить в том или ином свете, но понятно, что они бывают разные. Говоря об опыте проектов, получается, что проектный менеджер должен понимать с первой встречи, о какой модели экономического взаимодействия идет речь, либо проект для галочки, либо для результата. Это так?

 

Юрий Савилов: На самом деле, мы заранее не можем знать, это проект для галочки или этот проект действительно важный для бизнеса, для безопасности, для IT, никак не предугадаем. Есть требования, есть договор, есть метрики, мы начинаем работать, а как ее будет использовать заказчик. Может такая случится ситуация: сменилось руководство, руководство говорит, что это решение не входит bspraсtis, мы его использовать не будем, но так как уже внедрили, пусть оно постоит. Такие случаи тоже бывают.

 

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

 

Олег Седов: Спасибо. Мы переходим ко второму вопросу: «Как правило в стандартном проекте каждый участник проекта делает только свою задачу, от сих и до сих, при этом создавая возможностные косяки и погрешности на стыках, важен ли helicopterviewer». Мария, поясни, что это в твоем понимании и насколько он важен?

 

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

 

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

 

Юрий Савилов: Почти нечего возразить Марии. Но я, конечно же, попробую. Давайте начнем с термина "от сих, до сих". О том, что каждый участник, вовлеченный в проект, выполняет только что-то свое. Хочу сказать, что для достижения успеха, команда должна слаженно работать и каждый участник команды, должен понимать, какой цели, отталкиваясь от каких задач, движется его коллектив, чтобы завершить проект вовремя, качественно, чтобы заказчик был удовлетворен, ибо "срубить денег" и убежать, это неправильно. Это потеря имиджа, это потеря лица, это, как в сказке про мальчика, который кричал: "Волки, волки". Вся деревня бежала, хватала вилы. Два раза кричал, три, а на четвертый раз появились волки. Он закричал: "Волки", а никто не вышел, и волки всех перегрызли.

 

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

 

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

 

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

 

Юрий Савилов: Я предлагаю не вдаваться в подробности: контроль, управление. Давайте модель немного упростим, и пусть руководитель команды осуществляет и то, и другое.

 

Олег Седов: Два мяча на площадке.

 

Юрий Савилов: Хорошо, два мяча на площадке, что делать? Тогда либо кто-то в команде, капитан выкидывает один мяч, либо тренер подскочил, забрал этот мяч. Так, наверное, проще будет, быстро указать, что делать и куда двигаться. Хочу упомянуть уберизацию интеграторов, на больших проектах не пойдет.

 

Олег Седов: Пока.

 

Юрий Савилов: Да никогда не пойдет, уберизации трудно достичь даже в каком-то более приземленном бизнесе, типа ремонта квартир, такой непредсказуемый результат бывает. Не получится, трудно оценивать, трудно рейдинги собирать и так далее. Маленькие задачи, пожалуйста, большие, крупные проекты-никогда.

 

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

 

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

 

Олег Седов: Я думаю, пора переходить к голосованию, а пока отвечу на вопрос, который адресовали мне: «Как я вижу уберизацию интеграторов?»

 

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

 

-Третий вопрос: «Как оценить качество и компетентность проектных команд?»

 

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

 

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

 

Юрий Савилов: Очень хороший пример очень плохой команды. Что хочу сказать, разумеется, взваливать на одни плечи задачи нельзя. Это неразумно, неправильно, перед участием в проекте необходимо ресурсы в первую очередь зарезервировать, чтобы в случае форс-мажора, например: командировка, ладно, командировку можно было запланировать, это как раз плохое планирование, это, видимо вина руководителя проекта, который своего ключевого специалиста пытается "разорвать" на две точки. Поэтому качество проекта команды оценивается по результату, заранее составляется перечень участников, обязательно резервируются ключевые звенья этой команды. Если это инженер, то их должно быть один, два с необходимыми компетенциями, с необходимым опытом, и заказчик вправе требовать подтверждение опыта, образования, профильного, курсов дополнительных и всего прочего. Резервирование должно быть, это одно из условий, качественно выполненного в будущем проекта.

 

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

 

Каждая проектная команда представляет на таком ассесманте свое видение проекта, свою проектную команду и рассказывает о компетентностях каждого из участников. Здесь же дается право задавать абсолютно любые вопросы, в пределах допустимых возможностей, конечно, таким образом снижая риски того, что та или иная команда будет слабее и на выходе, результат ассесмант центра, они будут решающими - это раз, и, во-вторых, обязательное условие компании: компания исполнитель не может менять состав заявленной проектной команды. Это прописывается в договоре в виде дополнительного соглашения. Таким образом, после того как за практику взяли подобное обыгрывание конкурсов, провалов проектной команды стало в разы меньше. Люди стали задумываться о том, кого представлять заказчикам, чтобы выиграть тот или иной конкурс.

 

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

 

Мария Воронова: Как я уже сказала, включается обязательным пунктом в договор и компания - исполнитель обязуется выплатить неустойку в случаях такого форс-мажора.

 

Олег Седов: И команда исполнителей тем самым шантажирует свою компанию, этим же пунктом.

 

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

 

Олег Седов: Переходим к голосованию, а пока прокомментирую услышанное. Быть не должно и происходит, это не всегда одно и то же.

 

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

 

Мария Воронова: Абсолютно правильно задан ход дискуссии по данному вопросу. Очень часто исполнитель лукавит, обещая золотые горы, лишь бы продать проект, при этом не сообщая ни о возможных сложностях, рисках, проблемах с интеграцией, не совсем подходящей инфраструктуре на стороне заказчика. Это все умалчивается, а всплывает уже после, гораздо после, и хорошо бы к середине проекта, когда все идет, деньги вложены, и остановить нельзя. Но вот что касается примеров, хочу привести следующее.Стандартный проект по внедрению DLP-решения, как правильно заметил Олег, сотрудник подразделения продаж бегает вокруг клиентов, обещает, что все будет сделано, все взлетит моментально, все заработает и при этом не говорят, что потребуются дополнительные ресурсы либо со стороны исполнителя, а вообще со стороны заказчика настройки DLP - системы, а если в компании не внедрить необходимый пакет нормативной документации, то могут быть судебные претензии или иски со стороны сотрудников на предмет некорректного мониторинга информации, влезание в частную жизнь.

 

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

 

Ни о том здесь идет речь, а о том, что все эти нюансы максимально качественно, максимально подробно требуются впихнуть в начальные договоренности и большое число раз спросить: " а что если?", оговорив все возможные риски. И еще вопрос, Юрий, к тебе. Я, как заказчик, всегда удивлялась громоздким и огромным анкетам, которые очень любят рассылать как компании вендоры, так и компании интеграторы. И часто там бывают вопросы излишне подробные, либо, на мой взгляд, совсем бредовые. Вот зачем они вам эти анкеты?

 

Юрий Савилов: Спасибо, Мария. Давайте тогда начнем с анкет, так как это был последний вопрос. Анкеты необходимы, и чем подробнее анкета, тем больше шансов, что некоторые, даже не основные требования будут разобраны наиболее подробно. Зачастую заказчик может не представлять, что имеет ценность, важность для успешного выполнения проекта. Заказчик не всегда знает о нюансах, которые существуют при внедрении конкретной системы. Подрядчик же в курсе, имея необходимые компетенции, зная, где есть свои подводные камни, какие необходимы требования к сопрягающим системам, к оборудованию, к операционным системам, к серверам, то есть очень много в инфраструктуре заказчика элементов, которые нужно учесть как софт, так и железо. Поэтому грамотный, компетентный подрядчик обязательно все это проанализирует, проверит, получит основную долю ответов с помощью вот этих анкет. Если будет мало, будут еще анкеты, будут анкетированы представители различных подразделений вовлеченных в проект, это IT, ИБ, бизнес.

 

То есть максимально возможно изучить, обследовать как технически, так и аналитически, обозначить границы проекта, отталкиваясь от этих данных, полученных на этапе анализа, обозначить сроки и ответственности, и затем уже двигаться к намеченной цели. Я хочу сказать, что анкеты нужны, подробные опросы нужны, подрядчик должен иметь компетенции сообщить обо всех острых углах и ямах, камнях заказчику, чтобы не получилось вот как на картинке. Заказчик говорит: «Хочу автомобиль». « Хорошо, на тебе автомобиль. «А где двигатель?», а мы вам не сказали, что ли, извините, давайте заменим на то, что есть. Чтобы такого не было, все должно оговариваться заранее с обеих сторон.

 

Олег Седов: Мне одному кажется, что чем толще твоя анкета, тем формальней заказчик подходит к ответам на твои вопросы. В результате вместо реальной картины, ты получаешь формальную картину.

 

Юрий Савилов: Со стороны может показаться так. Заказчику может показаться так, и он попытается формально отмахнуться, действительно, но на то эксперты, они эксперты, чтобы получив ответы в этой анкете, еще и перепроверить самим, чтобы понять действительно ли это такие ответы, или заказчик где-то слукавил, отмахнулся, недопонял, а может и сам неправильно представляет картину. Это часто встречающийся случай, когда заказчик, например, не совсем компетентен, не владеет теми средствами, которые у него есть, которые у него в ЦОДе стоят: решения, soft, железо. Он может не владеть этой картиной, поэтому нужно помочь ему, вместе с ним пройти и посмотреть, отталкиваясь от его анкет.

 

Мария Воронова: А у меня по поводу этих анкет на самом деле есть еще свое мнение, которое сложилось в результате заполнения огромного количества таких анкет. Вот скажите, зачем мне в анкете на антифрод систему, с целью понять процессы, текущая техническая инфраструктура, запихивают вопрос: «Является ли моя компания оператором по персональным данным и выполнены ли все действия по проведению к комплаенсу в этой области». Иногда создается впечатление, что такие объемные анкеты, в том числе требуются для выявления слабых зон у клиентов, незакрытых со стороны информационной безопасности, чтобы чего-то по этому поводу предложить .

 

Юрий Савилов: А почему собственно и не предложить, если вы, например, сидите на пороховой бочке, а мы скажем вам об этом. На мой взгляд, это очень правильно.

 

Олег Седов: Мне кажется опять, что хитрый интегратор соскочил от прямого вопроса, ну что ж это его право, это его бизнес.

 

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

 

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

 

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

 

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

 

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

 

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

 

Юрий Савилов: Мария, спасибо. Текущий тезис перекликается с предыдущим у нас с вами. Для начала хочу сказать, что, да, бизнес нужно привлекать, объяснять, договариваться, так как это тот заказчик в абсолютном большинстве случае, которому система необходима. Что касается антипримера, который приведен с антифрод системой, можно брать куски из предыдущей нашей беседы и вставлять сюда. Недостаток аудита, недостаток планирования, и возможно, недостаток анкетирования, который вы так не любите. А там скорее всего была такая графа: "Есть ли у вас что-то для антифрода, используются у вас что-то?" И скорее всего, заказчик отмахнулся, а подрядчик был не очень обязательным и поверил на слово и не перепроверил.

 

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

 

Олег Седов: А кто здесь бизнес?

 

Юрий Савилов: А здесь зависит от того, кто педали крутит (смеется). Бизнес обычно показывает, в каком направлении двигаться, у него есть основная стратегия, основное направление, а все остальные этому бизнесу помогают достигнуть этой цели. Бизнес всегда главный.

 

Олег Седов: Мне очень понравился тезис на слайде, что бизнес главнее безопасности в 99% случаев. Но раскрытие этого тезиса напоминает чтение из моей любимой книги: "Как отвечать на вопрос прессы, если ты руководитель проекта". Не знаю, не убедили, мне кажется, вы очень много передергивали и меняли понятия бизнес процессы, следование и автоматизации бизнес процессов и их безопасность, потому что следовать автоматизации бизнес процессов так, как хочет бизнес, это не всегда правильно, но как в этом убедить, я не знаю, а вот безопасность этих процессов и рекомендации в вопросах безопасности управления рисками которые, исходят от вас - это следующий второй мега сложный вопрос. Попробуйте на него ответить.

 

Юрий Савилов: Упомянул немного ранее, что бизнес нужно привлекать на ранних стадиях проекта, еще на этапе переговоров, на этапе обследований, на этапе выяснения нужд и требований. И как раз, если на этой стадии бизнес смотрит не туда, говорит: « Я не хочу эти транзакции проверять, потому что проверка добавит 0,001 мили секунду ко времени транзакции, это задержка, это потерянные деньги». Естественно, ответственный компетентный подрядчик убедит бизнес , что это необходимо, это снизит репутационные риски, это сбережет Ваше лицо, сбережет Ваш карман. Предложат другой выход, разумеется, голую систему, никак не защищенную, ни один разумный подрядчик не оставит. Бизнес будет говорить, что я не хочу это защищать, подрядчик скажет надо. Давай найдем наиболее приемлемый вари ант который устроит Вас.

 

Олег Седов: Он точно так скажет, Мария?

 

Мария Воронова: Бизнес, как правило, говорит, да, я хочу защищать - защищайте, но я не хочу за это платить, это первое. А второе, вы откровенно верите, что бизнес на этапе предпроектного, когда еще договора неподписаны, деньги не выделены, будет заполнять анкеты. На мой взгляд, это тоже утопия, потому что кого-то из стейкхолдеров бизнесов в крупных компаниях отловить, а тем более на встречу с каким-то непонятным интегратором в области ИБ, практически нереально. Иногда, конечно, получается, но как раз в 1% случаев из возможных 99%.

 

Юрий Савилов: Позвольте, небольшую реплику. Я не припомню случая, когда проект обсуждался напрямую с руководителем компании, руководителем организации подрядчика.

 

Олег Седов: А хотелось бы?

 

Юрий Савилов: Разумеется, это бессмысленно в большинстве случаев. Есть люди, ответственные как с той, так и с иной стороны, которые делегировали полномочия и могут принимать решения от имени своих компаний. Это не должен быть директор.

 

Мария Воронова: Стейкхолдеры - это те, кто выделяют деньги. Поэтому для проекта, для старта проекта, их надо убедить в том, что нужно.

 

Олег Седов Я позволю себе несколько реплик, Юрий, во-первых, мне всегда казалось, когда заходит речь о репутации в российских компаниях, то мне кажется, что в словосочетании «репутационые риски ржд», одно слово лишнее, а какое, каждый выбирает для себя сам. Я благодарен нашим участникам за то, что они попытались сымитировать батл, сказать, что это был батл, не уверен, они все-таки пытались как заказчик с исполнителем договариваться между собой и, видимо, это нормальные отношения, практика партнерства заказчика с исполнителем. С другой стороны, в жизни ситуации бывают гораздо жестче, и тот, кто работал с монстрами, он знает, монстрами-заказчиками я имею в виду, у которых огромные бюджеты и огромные юридические ресурсы, вот тут начинаются большие проблемы и тут очень сложно договориться, особенно маленькому интегратору с большой компанией. Вот здесь масса проблем, которые мы не смогли обсудить, но видимо, это тема сегодня закрыта не будет.