Ижорский трубный завод (ИТЗ) — новое предприятие группы «Северсталь», введенное в эксплуатацию в июле 2006 года. Одновременно с монтажом оборудования на заводе началось внедрение ИС на основе Oracle e-Business Suite. В связи с этим проектом на ИТЗ были выработаны принципы управления проектными рисками. О них рассказывает Тимофей Левицкий, начальник управления ИТ ЗАО «ИТЗ».

Intelligent Enterprise: Расскажите о проекте внедрения Oracle e-Business Suite на вашем предприятии. Как и на каком его этапе вы начали анализировать риски?

Тимофей Левицкий: Завод входит в группу «Северсталь», и выбор ИС был предопределен стратегией группы. Да, в системе есть ряд возможностей, которые, вероятно, не понадобятся заводу; зато мы следуем по наиболее эффективному пути: настраиваем то, что уже создано программистами Oracle, а не дописываем более простую систему. Первый этап проекта предусматривал внедрение модуля управления логистикой — автоматизацию прихода и расхода товарно-материальных ценностей, складов. Второй этап — внедрение модулей управления финансами и персоналом. Сейчас мы не внедряем ничего лишнего, например, в проекте нет модуля управления ремонтами. Когда пройдет время и завод выработает свою стратегию технического обслуживания, которую нужно будет автоматизировать, мы вернемся к этому модулю. А поскольку у нас всего два здания и одна автоматизированная линия, нам не требуется модуль управления имуществом.

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

Чуть позже, одновременно с детализацией проекта, мы формализовали своё видение рисков — составили таблицу, где были следующие столбцы: «Что может случиться?», «Какова вероятность того, что это случится?», «На каком этапе проекта это может случиться?», «Насколько сильно это повлияет на результат проекта?», «Что нужно делать, чтобы этого не случилось?», «Что мы будем делать, если это все-таки произойдет?».

Кто принимал участие в анализе рисков? Насколько в этой работе можно использовать опыт внешних консультантов?

В составлении этой таблицы участвовали руководители проекта со стороны завода и со стороны компании-исполнителя («КОРУС Консалтинг»), а также архитектор системы со стороны исполнителя. Кроме того, были опрошены все доступные на тот момент бизнес-эксперты в области трубного производства, технологи, производственники, инженеры... Они собирались и обсуждали ситуации, когда что-то может случиться. Особо хотел бы отметить, что при определении самих рисков нельзя останавливаться на таких понятиях, как «затянем сроки на 20%» или «выйдем за бюджет на 30%». Риск состоит в том, что какая-то конкретная работа пойдет не так, а уже из-за этого будут превышены сроки или бюджет.

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

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

Выявление потенциальных рисков — практически бесконечная задача. Сколько рисков было в вашем перечне? Какие из них наиболее значительны?

В нашей матрице рисков содержалось около 20 строк. Это немного, в более сложных проектах их должно быть больше. Но наши риски были очень разными. Был риск, связанный с персоналом: что мы не найдем людей на определенные позиции. И он реализовался, мы действительно не смогли найти нужного нам специалиста в службу поддержки — но вместо него взяли на работу двоих студентов, которые хорошо справляются с этими обязанностями. Другой пример — риск, что вовремя не поставят и не смонтируют оборудование и не запустят АСУТП. Я оценил такую вероятность как риск и продумал способ борьбы с ним — дополнительные переговоры с поставщиком. Но сейчас я понимаю, что это не риск, а неизбежность: так бывает практически всегда. Да, поставщики не смонтировали оборудование вовремя, и АСУТП запустили на два месяца позже плановых сроков. Мы пытались как-то повлиять на это, но нам сказали, что не запускается транспортная система, отвечающая за движение трубы по автоматизированной линии, а это важнее нашего проекта. И здесь никакой план борьбы с рисками нам не помог — мы просто сидели и ждали своей очереди.

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

Насколько значителен риск того, что персонал компании будет отторгать проект?

Для нас этот риск очень значителен. Есть предприятия, которые могут позволить себе просто уволить всех, кто не хочет работать по-новому. Потому что этих сотрудников легко заменить. У нас в трубной отрасли все не так. Труба делается из одной детали — листа металла. Настроить станок так, чтобы 18-метровый лист правильно гнулся, может только опытный мастер, а испорченная труба — это 25 тысяч долларов убытка. Здесь все зависит от навыков, а не от автоматизации, мастера чувствуют металл. И разгонять пожилых мастеров категорически нельзя.

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

Вы упомянули, что существуют события, которые можно принять за риск, а на самом деле они неизбежны. Как определить такие события?

Событие, вероятность которого составляет 90%, — это не риск, а надвигающаяся угроза. Надо уже бить тревогу. Я уверен, что если шанс какого-то опасного события превышает 50%, то уже надо не расценивать его как риск, а готовиться к тому, что оно точно произойдет.

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

Еще одно обстоятельство, которое мы уже не считаем риском, — это повреждения и поломки в ИТ-инфраструктуре. Мы внедряем информационную систему на строящемся предприятии. У нас вокруг сплошная стройка, а значит, ИТ-инфраструктура просто физически не может быть на 100% надежной. Поэтому мы предусматриваем пути решения возникающих проблем. Так, на заводе установлена АСУТП, которая отслеживает движение трубы по автоматизированной линии. Oracle E-Business Suite фактичеcки дублирует работу этой системы. Но у нас все равно есть сотрудники, учитывающие, что обе системы могут перестать работать. На этот случай разработаны специальные журналы и формы, информация в которые будет заноситься вручную. В данном случае риск — это сбой в работе в конкретный момент, но то, что периодически такая проблема будет возникать, — совершенно точно.

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

Вы применяли методы количественной оценки рисков?

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

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

В этой связи — насколько действенны предусмотренные заранее пути минимизации риска? Можно ли все распланировать загодя?

Здесь и возникает проблема симметричного и несимметричного ответа на риск. Традиционные способы противодействия рискам в проектах внедрения информационной системы могут оказаться неэффективными. Например, в связи с риском перерасхода денежных средств в бюджет можно заложить дополнительные средства или хотя бы предупредить лица, финансирующие проект, о вероятности такого перерасхода. Если существует риск не найти нужного специалиста, в таблице рисков можно записать, что в этом случае мы попросим исполнителя проекта найти нам такого специалиста. Это всё попытки решать проблему «в лоб», но в сложных проектах они часто не работают. И решать надо не «в лоб», а «в обход». Невозможно парировать риск нехватки рабочей силы просто путем набора сотрудников, потому что если бы это было так просто, то и риска не было бы! Нужно разработать, скажем, план по привлечению аутсорсинговых компаний или план по переносу части работ на будущие периоды.

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

Возможна ли, на ваш взгляд, страховка проектных рисков?

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

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