Темой нашей очередной беседы за круглым столом стали риски, возникающие при реализации проектов с ИТ-составляющей.
Участники круглого стола:
Андрей Михайлов, директор по ИТ Lady&Gentlеman City
Игорь Шишков, руководитель отдела информационных технологий ЗАО «Стальпрокат»
Алексей Картышев, директор департамента информационных технологий Runway
Александр Артюхов, директор по технологиям и развитию бизнеса INCITY DESEO
Михаил Заборов, заместитель директора по стратегическим проектам CUSTIS
Intelligent Enterprise: Какие разновидности рисков следует относить преимущественно к области ИT? Какие управленческие решения надо принимать, чтобы минимизировать потери при внедрении ИТ-проектов?
Александр Артюхов: Есть корпоративная информационная система, состоящая из следующих элементов — инфраструктуры, приложений, а также собственно ИТ-службы и сервисов, системы коммуникаций, регламентов, процессов, инструкций, которые описывают взаимодействие всех перечисленных элементов. И ИТ-проектом следует считать только тот проект, который связан с развитием этих подсистем, но в то же время никоим образом не выходит за пределы ИТ-службы. Проекты по автоматизации бизнес-процессов, строго говоря, считать ИТ-проектами нельзя, хотя там и есть ИТ-составляющая.
Андрей Михайлов: Тем не менее пласт внутренних проектов ИТ-службы весьма велик и важен. И для него также актуален вопрос рисков.
Михаил Заборов: ИТ-проектами можно считать всё, что имеет ИТ-составляющую, связанную с внедрением или доработкой какой-либо системы. Но есть более серьезный терминологический вопрос: а что такое собственно риски? Обычно при реализации проектов возникает некий образ будущего. А риски — это такие ситуации, когда реальное течение проекта отклоняется от этого образа, причем нежелательным для нас путём. У такого рода событий есть определенная вероятность. И чем детальнее мы представляем себе будущее, тем точнее можно планировать процесс движения к нему, тем более обоснованно мы можем говорить о рисках и лучше идентифицировать их. Именно это называется рисками, если объяснять «на пальцах».
Но когда мы внедряем новую ИТ-систему, наши требования к ней в любой момент могут измениться. А это уже не риск, а часть процесса. Хотя это не снимает вопрос о качестве проекта.
Алексей Картышев: И всё же у любого проекта есть цель, а часто и несколько целей. И любое событие, которое может как-то повлиять на достижение этой цели, является риском.
Михаил Заборов: А что делать, если сама цель в ходе проекта поменяется? Будет ли это для вас катастрофой? Тогда это тоже риск. А если всё прошло нормальным, естественным образом, то уже нет? А если вы начали внедрять «тяжелую» систему, например ERP, но в ходе проекта поняли, что она вам просто не нужна? Считать ли это риском?
В чем состоит управление рисками на практике? Напротив каждого риска мы ставим ущерб, который он наносит, и вероятность его возникновения. Само управление рисками начинается дальше, когда мы решаем, будем ли мы уменьшать вероятность возникновения той или иной ситуации (и что именно будем тогда делать), а также что мы будем делать, если нежелательное событие всё же произойдёт. В некоторых случаях мы можем просто принять конкретный риск (то есть ничего не будем делать).
Если же говорить о классификации рисков, то основным признаком, по которому имеет смысл их различать, является объем наносимого ущерба. Ущерб практически всегда целиком приходится на бизнес. Поэтому не очень корректно разделять риски бизнеса и ИТ-службы. Хотя теоретически можно попытаться классифицировать риски по тому, кто именно (ИТ-отдел или бизнес) является виновником их возникновения, однако это далеко не всегда можно определить корректно.
Когда внедренное решение не работает вообще или работает не так, как хотелось бы, то ИТ-подразделение склонно обвинять бизнес в том, что задача была неправильно или нечетко сформулирована. С другой стороны, бизнес резонно может возразить, что это ИТ-служба его неправильно поняла или выбрала неправильное решение. Делить вину между тем, кто плохо понял, и тем, кто неверно сформулировал задачу, бессмысленно. Это всегда двусторонний процесс.
Александр Артюхов: Когда поменялась цель, то это уже другой проект.
Алексей Картышев: Соглашусь с Михаилом. Имеет смысл рассматривать риски при внедрении той или иной системы. А вот искать ответы на вопрос о том, связаны они с ИТ или нет, обычно не продуктивно.
Intelligent Enterprise: Насколько правильно выделять ИТ-риски из других категорий рисков: операционных, стратегических, связанных с нарушением деловой репутации или сбоями в оперативном управлении компанией?
Сергей Костяков: Обычно ИТ-служба считает вопрос управления рисками своей вотчиной. Но все же риски существуют не только в ИТ. Насколько хорошо развиты в бизнес-подразделениях навыки по практическому управлению рисками? Можно ли говорить о том, что сложилась соответствующая корпоративная культура?
Александр Артюхов: Вопросы, связанные с управлением рисками применительно к любым проектам, звучат нечасто. А для бизнес-заказчика ИТ-риски незаметны, а то и вовсе не существуют, если сотрудники ИТ-службы им об этом не напоминают. Наверное, именно поэтому риски в большей степени связываются с ИТ. Тем более что всё это описано в лучших практиках и болееменее формализовано. То же управление доступностью в ITIL по сути сводится к управлению рисками: речь идет о рисках неполучения бизнесом той или иной ИТ-услуги. В итоге ИТ-риск, не очевидный для бизнеса, трансформируется в нечто другое, что уже более понятно: риски потери репутации и клиентов, упущенной выгоды и тому подобное. Если же речь идет о чисто ИТ-рисках, то это бизнес рассматривает как внутреннее дело ИТ-службы, на которое к тому же обычно не выделяются необходимые ресурсы. Но ведь эти риски относятся также и к бизнесу, чего «большие» руководители не понимают. Одно дело, когда бизнес принимает эти риски и снимает с ИТ-директора ответственность за их последствия. Но после наступления такого случая ИТ-директора всё равно могут уволить — дескать, мало было просто предупредить, «нужно было донести».
Вот простой пример. Есть ИТ-инфраструктура, на которой работает ERP-система. При этом подсистема хранения данных не резервирована, хотя все же делаются бэкапы. Представим себе, что вышел из строя дисковый массив, на котором размещена основная база данных. Работала эта СХД шесть лет, и вот на седьмой произошел наконец сбой. В итоге просто не читается одна из таблиц. Сколько времени займет ее восстановление? И ведь потребуется еще заново вносить данные, которые изменились с момента создания последней резервной копии. Восстановление после такой аварии может занять и двое суток, всё это время компания будет простаивать. Примем цену простоя в 40 тыс. долларов в час, что вполне реально. В итоге ущерб составит порядка 2 млн. Стоимость же резервной СХД на порядок меньше. И кто тут виноват? Бизнес, который не выделял средства, или ИТ-директор, который не донес до бизнеса возможные последствия?
Андрей Михайлов: Рисками хорошо пугать бизнес. Ему становится страшно, и меньше проблем с выделением бюджетов. Ну а если серьезно, то последствия рисков, связанных с ИТ, устранять проще всего. Они ведь описаны в лучших практиках.
Михаил Заборов: Когда мы говорим об эксплуатации ИТ-систем, а не об их развитии, корректнее употреблять термин «качество», а не «риски». Качество — это заданные характеристики работы аппаратнопрограммных систем. Бизнес просто ожидает того, что система будет им соответствовать. Когда речь идет о сложном комплексе, то таких критериев будет несколько, однако среди них всегда выделяются ключевые.
И правда жизни состоит в том, что эти критерии часто находятся между собой в конфликте и добавление каждого нового стоит денег. В итоге выбор приоритетов для критериев качества является довольно сложным процессом и приходится идти на те или иные жертвы для того, чтобы не пострадали ключевые функциональные параметры и при этом стоимость не зашкаливала.
Чем конкретно придется пожертвовать — определяется в ходе диалога между бизнесом и ИТ-подразделением. Бизнес выставляет свои пожелания, а ИТ-служба — стоимость их реализации. То, что бизнесом ценится высоко и недорого, не обсуждается и просто делается. Дискуссия возникает, когда реализация ключевых для бизнеса характеристик требует больших усилий и соответственно больших затрат. Всё это хорошо описано в такой дисциплине, как архитектурное проектирование программных продуктов.
Прибегая к популярной автомобильной аналогии, мы не закладываем риски на то, что какой-то узел выйдет из строя. Мы оперируем другими терминами, связанными с качеством всего автомобиля. Риски, конечно, хороший инструмент, но далеко не всегда удобный. О них много говорят, но ими мало кто занимается так, как это описано в PMBok. Есть более удобные инструменты, которые решают те же самые задачи.
Intelligent Enterprise: Какие основные параметры ИТ-систем рассматриваются при управлении рисками в проектах автоматизации компании? Связаны ли оценки в большинстве случаев с рассчитываемыми финансовыми потерями, или, скажем, вполне можно остановиться на фиксировании некоторых возможных проблем, связанных с человеческим фактором?
Михаил Заборов: У риска есть три числовых показателя: возможный ущерб, вероятность возникновения и затраты на устранение последствий. Они соотносятся, и принимается решение. В том примере, который привел Александр, не было вероятности, хотя был известен ущерб и стоимость компенсационных мер. Если что-то подобное происходит раз в год и чаще, то меры принимать однозначно надо. Если раз в пять лет, то вполне можно оставить всё как есть.
Александр Артюхов: Да, а для этого надо глубоко знать бизнес. Что же касается описанного инцидента, то далеко не каждый бизнес согласится нести такой ущерб. К тому же проценты, в которых измеряется уровень ка¬чества сервиса, никто не понимает. Бизнес вряд ли готов тратить десять миллионов при стоимости ущерба в два миллиона. Но если возможная потеря составит сто миллионов, то бизнес уже начнет задумываться.
ИТ-директор берет деньги не из своего кармана. Их дает бизнес. Причем с определенными условиями, исходя из своих интересов. И роль ИТ-директора состоит в том, чтобы устранить все ненужные риски в рамках бюджета и полномочий, которые он получил. Но все равно в 90 % случаев ИТ-директором, мягко говоря, не будут довольны.
Существуют и проблемы, связанные с человеческим фактором. Например, есть уникальная самописная система, работающая уже много лет. И есть один или два сотрудника, которые знают, как она работает. А других специалистов по ней нет. О том, какой риск связан с уходом одного из этих сотрудников, говорить не нужно. И некоторые из таких специалистов этим пользуются в своих интересах. Причём на выполнение их условий обычно идут, потому что замена уникальной системы будет стоит дороже. Да если даже и появилась замена, все равно какое-то время приходится две системы использовать параллельно. И при этом, видя, что делаются попытки избавиться от старой команды, некоторые её представители могут начать строить козни. Это риски, никак не связанные с ИТ.
Андрей Михайлов: Да, деньги дали, а оборудование не доехало. Или неисправность случилась тогда, когда новую систему не успели запустить.
Intelligent Enterprise: А что можно сказать о численном описании вероятных последствий и о возможности взаимодействия — как на поле этих численных показателей, так и в сфере качественных оценок? И соответственно о разделении ответственности за результат проектов в бизнесе и ИТ-службе?
Михаил Заборов: То, что бизнес не понимает оценок, выраженных в виде численных показателей вероятности, — явное преувеличение. Интуитивно они используются. Все болееменее понимают, например, когда надо летнюю резину менять на зимнюю и наоборот. Вполне типичный случай того, когда надо взвешивать риски и затраты.
Александр Артюхов: Откуда берутся эти числа? Когда внедряется каталог услуг, на чем вы базируетесь? На прошлом опыте? А если его нет? Тут остаются здравый смысл и доступные ресурсы. На них и приходится базироваться. В итоге становится ясно, какие заявки с какой скоростью надо выполнять. Есть такие, где скорость решения должна измеряться минутами, где-то — часами, а есть заявки, от неисполнения которых даже в течение нескольких недель ничего страшного не произойдет. Если с подобным подходом все соглашаются, то хорошо. А дальше начинает работать статистика. Да, говорят, что ITIL хорошо оцифрована. Но откуда получены эти цифры? Уверен, что в каждой компании ситуация с цифрами может отличаться от так называемых «лучших практик». Иногда кардинально.
И что касается управления рисками, то, как та блондинка из анекдота, приходится говорить, что вероятность того или иного инцидента, например, связанного с выходом критически важного оборудования из строя, составляет 50 %. Или сломается, или нет. Заявленные показатели надежности или наработки на отказ действительно очень тяжело донести до бизнес-заказчика. А вот претензии по поводу того, что, мол, деньги потрачены, но ничего не случилось, становятся уже рисками ИТ-директора.
То же с выбором оборудования. Не надо напоминать, что дешевая система может оказаться дороже в эксплуатации, чем более дорогая от солидного сборщика. Но решение о выборе бизнес-заказчик всё равно принимает сам. На основании ли собственного или чужого опыта, на основании ли статистики или без таковой…
Алексей Картышев: Обычно считают, что коль скоро речь идет об ИТ-проекте, то за него отвечает ИТ-директор. Но это неправильно, особенно если проект крупный. Необходим некий проектный офис, сформированный из экспертов. Он и должен выявить максимально возможное количество рисков. Иначе многие риски не будут учтены просто потому, что узкие специалисты как со стороны бизнеса, так и со стороны ИТ не увидят тех проблем, которые лежат вне их компетенции. Да и в любом случае взгляд со стороны полезен всегда. Но бизнесу это объяснить не так просто.
Андрей Михайлов: В компании должна быть культура ведения проектов. В целом ИТ-подразделение более организованно, но его сотрудники говорят на не вполне понятном для бизнеса языке, и поэтому возникают проблемы взаимодействия с бизнесом.
Сергей Костяков: В силу должностных обязанностей мне приходится бывать на встречах руководителей функциональных служб. И от них зачастую слышишь всё те же жалобы на то, что бизнес их не понимает.
Игорь Шишков: Попробуем посмотреть на вопрос более глобально. Посмотрим на статистику, сколько ИТ-проектов заканчивается неудачно. Ещё в 60-е годы ХХ века академик Виктор Михайлович Глушков разработал несколько прин¬ципов, которые позволяют сделать ИТ-проект успешным, довести его до логического завершения. И один из них состоит в том, чтобы заинтересовать первое лицо компании. Это должен быть не главный бухгалтер и в любом случае не «чистый» исполнитель. Именно у первого руководителя (в современной терминологии генерального директора или, скажем, собственника) должна быть заинтересованность в том, чтобы проект был завершен. И если это удалось, то 70—80 % рисков снимается автоматически. Да и нам, ИТ-специалистам, что-то обосновать станет проще. Нас хотя бы будут слушать.
Но есть и обратная сторона. Бывает так, что первое лицо активно начинает различные проекты, в том числе и в области информационных технологий. Но через какое-то время интерес теряется, и все эти проекты, что называется, зависают. В результате процесс завершения таких проектов становится довольно сложной задачей, равно как и обоснование затрат на них. Чтобы этого не произошло, довольно часто приходится выступать в роли «адвоката дьявола» и дотошно разбираться, насколько в действительности нужен тот или иной проект, инициированный первым лицом с такими вот особенностями. Данная проблема может возникать не только в случаях с ИТ-проектами.
Часто бывает так, что параллельно идет несколько проектов, причем не все они относятся к сфере ИТ. Например, заменяется ERP-система. Параллельно идет смена одного юридического лица на другое. Причем речь идет о крупной, территориально распределенной компании, имеющей филиалы в регионах и связанной договорами с большим количеством контрагентов. Кроме того, идет подготовка к открытию филиала, или, правильнее сказать, производственной площадки. Это завод, точнее, его руины, которые достались за долги. И туда надо провести все коммуникации и включить данный завод в существующую информационную инфраструктуру. Причем завод этот должен изменить номенклатуру продукции, которую выпускает компания. Можно ли это считать ИТ-проектом? Наверное, не совсем. Тем не менее понятно, что все эти проекты в той или иной степени имеют в себе ИТ-составляющую, риски при реализации которой во многом связаны с основными процессами, выполняемыми другими подразделениями компании.
Тут уже поднимался вопрос о CRM-системах. А когда проект ее внедрения можно считать целесообразным? С одной стороны, мечта любого руководителя — отделить информацию о клиентах от личности менеджера. Но сколько таких клиентов должно быть у компании или ее филиала, чтобы CRM окупила себя? Допустим, во всем регионе тысяча потенциальных заказчиков нашей продукции, из них реально покупает около двухсот. С некоторыми усилиями это число можно увеличить еще на дветри сотни. Нужна ли в этом случае CRM-система?
Андрей Михайлов: Это довольно типичная ситуация. Тут помогут только быстрые результаты. Тогда интерес к проекту можно снова поднять. Хотя что делать, если уже куплен, например, земельный участок для строительства центра обработки данных, большой вопрос. А то, что ИТ-директора привлекают к работе над бизнес¬проектами, является показателем высокого доверия к нему.
Алексей Картышев: Что касается успеха проекта, то всё зависит от критериев. То, что система внедрена, еще не означает, что проект завершился успешно. Она должна какое-то время поработать, чтобы оценить результат. Причем время это может быть довольно значительным. Например, для такой задачи, как внедрение системы планирования ассортимента, речь идет как минимум о двух годах эксплуатации. Так что успешное достижение задач, поставленных в ходе проекта, не означает общего его успеха. Причем таких критериев может быть несколько. И для каждого существуют свои риски.
Михаил Заборов: Ситуацию, когда риски оцениваются не в числовых параметрах, можно сравнить с тем, какие цели вы ставите перед собой, отдавая ребенка в ту или иную секцию. Достижение успеха в соответствующей сфере тут далеко не главный фактор. Зато ребенок всегда под присмотром и точно занимается чем-то болееменее полезным. Хотя тут есть и минусы: меньше свободного времени, чаще расстраивается из-за того, что что-то не получается. Все эти плюсы и минусы расписываются в двух колонках, и оценивается, что в итоге перевешивает. С проектом, который описал Андрей, всё точно так же. Внедрив CRM-систему, можно заработать репутационные бонусы, а можно еще и закрыть этим проектом какие-то риски.
Что касается влияния первого лица, то оно, конечно, есть. Один из главных проектных рисков состоит в потере энергетики, на которую владелец или высший руководитель, безусловно, влияют. Но для больших компаний этого может быть мало. Тут важную роль играет регламент. И нужно встроиться в этот регламент так, чтобы проект обязательно был закончен. Одним из вариантов здесь является создание проектного офиса. Хотя это крайне затратная процедура относительно времени людей, которые в ней задействованы. Да и сроки увеличиваются. Ведь вся эта конструкция начинает работать за счет того, что все вовлеченные в нее понимают, что в какой-то момент могут стать «крайними». В итоге все работают не на быстрый результат, а чтобы не «подставиться». У всех есть текущая работа, которую никто не снимал и за выполнение которой спрашивают. А вот работа в проектном офисе часто рассматривается если не как общественная нагрузка, то близко к тому. Эти вопросы в принципе решаемы. Но участие в таком проекте харизматичного заинтересованного лица позволяет делать его эффективнее, быстрее и с меньшими затратами. Причем совсем не обязательно, чтобы это было одно из первых лиц компании. Это вполне может быть руководитель функционального направления, кровно заинтересованный в проекте.
Многие проблемы идут от того, что к ИТ-проектам долго относились как к производственному конвейеру. Аналитик создает полные функциональные требования. Дизайнер переводит их в технический дизайн (архитектуру). Программист, следуя техническому дизайну, пишет программный код. Тестеры проверяют функционал программного кода и т. д. Но то, что работало применительно к какому-нибудь сортовому прокату, или чугунному литью, или любому другому более сложному, но четко определенному производст¬ву, оказалось плохо применимо к ИТ. Ведь в случае ИТ-проекта цель не определена до конца и постоянно меняется. Со своей стороны разработчики и консультанты жалуются, что клиент не знает, чего он хочет. И это действительно так. Даже больше — клиент зачастую не в состоянии сформулировать свои пожелания, пока не увидит первые результаты. И классический проектный офис тоже настроен скорее на заводской конвейер, чем на проекты внедрения ИТ-решений. Когда в ходе проекта возникает своего рода «зона высокой турбулентности», меняется 80 % требований, то необходимы совершенно другие подходы. Есть задачи, для которых можно использовать проектный офис, но их перечень ограничен.
Андрей Михайлов: Но бывает и так, что вроде бы ничего нового не получили, а все довольны. Поучаствовали в процессе, чему-то научились. А что касается проектного офиса, то под этим часто подразумевается просто группа людей, которая хоть что-то делает. Причем ее можно собрать в условиях полного хаоса, когда практически отсутствуют время и материальные ресурсы, но сверху поставлена задача что-то реализовать.
Алексей Картышев: В ходе проектов часто приходится что-то менять в бизнес-процессах. И ИТ-служба не всегда может принять все необходимые решения. В любом случае нужен взгляд со стороны для того, чтобы сделать это максимально эффективно, будь то изменения в системе или в бизнес-процессах. И бизнес, и ИТ-департамент самостоятельно, по отдельности сделать этого не смогут.
Игорь Шишков: Проведу небольшую аналогию, касающуюся идеи проектного офиса. В 80-е годы в нашей стране активно развивались военно-космические силы. Я тогда учился как раз по этому профилю. Нас, по-современному ИТ-специалистов, наряду с другими специалистами (боевого, технического, тылового обеспечения и пр.), планировалось использовать в группах боевого управления, которые создавались в той или иной чрезвычайной ситуации. С этой целью в каждой части было организовано некое подобие ситуационного центра, который оснащался несколькими ЭВМ с десятками программ. И там по заранее разработанным алгоритмам просчитывались вероятности наступления различных событий и их последствий, производилась оценка состояния наших сил и уровень нанесенного нам ущерба, прогнозировалось, как будет развиваться ситуация во времени. На основе полученных данных выдавались рекомендации относительно того, какие меры необходимо принимать в сложившейся ситуации. В армии, как и в бизнесе, однако, всё дается во власть командирам. Они могут следовать рекомендациям специалистов, но могут принять свое собственное решение. Но ответственность за принятое решение в любом случае несет только командир. Если командир отверг предложения специалистов и принял решение непродуманное и заведомо неправильное, приведшее к тяжким последствиям, то скрыть этот факт и свалить на кого-то вину за поражение будет невозможно. Избавиться от подчиненного, который предлагал правильное решение, но в итоге не смог его продавить, в армии сложнее. Особенно если после этого часть не выполнила боевую задачу и тем более потеряла боеспособность. В бизнесе же уволить такого сотрудника очень просто, и часто с ними так и поступают. Но в целом аналогия почти полная.
Михаил Заборов: Все-таки в бизнесе приходится решать принципиально иные задачи, нежели в армии, и совершенно в других условиях. Плюс ко всему про ИТ сложно говорить с позиции бизнеса. И действительно, бизнес-заказчик если и разбирается в ИТ-оборудовании и в том, как оно функционирует, то скорее весьма приблизительно. Прибегнем к той же автомобильной аналогии. Автослесарь предлагает мне на выбор две заслонки: медную и латунную. И как я могу выбрать? Я не специалист в области законов теплообмена и свойств этих материалов и не знаю, что мне лучше подходит.
Надо понимать, что бизнес часто не может четко сформулировать свои требования потому, что сам находится в зоне неопределенности. На него давят клиенты, рынок, регуляторы и многое другое.
Александр Артюхов: Вот тут возникла тема проектного офиса, связанная с тем, что хорошо бы иметь взгляд со стороны. Не думаю, что первое лицо компании будет слепо доверять любому консультанту, особенно если он пришел извне и его видят в первый раз. Сначала докажи свою компетентность. И если первое лицо решит, что ему не нужна автоматизированная система планирования и с данной задачей справятся два специалиста с помощью обычных офисных инструментов, то это его решение. Тут первое лицо берет на себя все возможные риски. И подход в данном случае должен быть такой же, как в армии. ИТ-служба — лишь одно из подразделений, выполняющих сервисные функции. Ей остается только принять это решение как данность. Хвост не должен вилять собакой.
Intelligent Enterprise: Можно ли с помощью ИТ-решений минимизировать последствия рисков, не связанных с ИТ, или, наоборот, могут возникнуть ситуации, когда вследствие неправильных действий ИТ-система, не решая основных задач, по сути лишь выставляет напоказ проблемы бизнеса?
Александр Артюхов: Есть универсальные инструменты, способные минимизировать по меньшей мере 80 % рисков с использованием 20 % ресурсов. Это мониторинг процессов, контроль и профилактика, связанная с системой управления изменениями: написание инструкций и обучение. Системы мониторинга являются неотъемлемой частью оборудования и системного ПО. Контроль можно вести с помощью систем отчетности. Плюс два человека, один из которых составляет документацию, а другой обучает остальных. Достаточно просто научить людей выполнять свою работу по четким инструкциям. Это избавит персонал от боязни нажать не на ту кнопку. И системы автоматизации должны быть максимально «дуракоустойчивыми», чтобы у линейного персонала не было возможности влезать куда не следует.
Сергей Костяков: Тут вскользь уже говорилось о риске, связанном с вероятностью ухода ключевых сотрудников. В этом случае может помочь система управления знаниями. Сейчас много говорят о внедрении систем фрод-менеджмента, которые позволяют снизить риски, связанные с присвоением имущества компании. Есть ли другие проверенные сочетания, которые можно рекомендовать?
Михаил Заборов: Здесь уже упоминалась ситуация с ненужными проектами. Если она типовая для компании, то это как раз классический риск и с ним нужно соответственно работать. Для начала его следует явно обозначить и обговорить со всеми сторонами, что делать, если он вдруг возникнет, и какой от него будет ущерб. В этом случае проект с большой долей вероятности просто не начнется.
Андрей Михайлов: Как-то пришлось столкнуться с проблемами при внедрении СЭД. Проект получил поддержку руководства, и вроде бы всё было хорошо. Но заказчик выдвинул требование, чтобы отклоненные документы просто исчезали из системы, иначе о подписании акта о приеме системы в промышленную эксплуатацию не могло быть и речи. Однако такой возможности в СЭД не было предусмотрено. Да и сам проект был начат именно для того, чтобы документы никуда не исчезали. Это мы сначала обошли, а потом и бизнес-процесс выправился.
