Какой вы видите стратегию развития компании?
Наша стратегия основана на стратегии Росатома. Необходимо обеспечить выполнение портфеля заказов на строительство АЭС в части своей зоны ответственности. И занимаясь решением этой задачи, прежде всего мы хотим сократить временны́е затраты для инженерного состава.
Это обусловлено тем, что на рынке не так уж много квалифицированных специалистов, да еще и со знанием английского языка. И даже высококвалифицированных специалистов необходимо еще обучить проектированию, на это уходит время, которого у нас, к сожалению, нет. Если мы соптимизируем процессы в работе инженеров, то у них, а стало быть, и у нас появятся ресурсы, которых сегодня так не хватает.
Что для этого нужно?
Прежде всего, необходимо выстроить четкую бизнес-модель проектирования, используя цифровую модель и схемы работы с требованиями, конфигурацией, рисками, НТД (нормативно-технической документацией), ИДП (исходными данными для проектирования), процедурами.
Цифровая модель — это только верхушка айсберга, итог интеллектуальной деятельности. А «под водой» — огромный процесс. Если схематично, то все начинается с заказчика, от которого мы получаем входные данные, требования к проекту в виде контракта. Все эти требования необходимо декомпозировать до уровня управления проектом — главного инженера, директора проекта.
Они, в свою очередь, собирают данные, заключают договоры, привлекают сторонние организации. Затем все работы распределяются между специальностями внутри проектного института и между субподрядчиками каждой из специальностей. Под каждый проект готовится карта разделения ответственности, описывающая взаимодействия между специалистами и подразделениями. Далее появляются планы управления специальностями: каждый отдел, каждая группа, каждый специалист получает полностью декомпозированные обязательства, в соответствии с которыми они должны спроектировать свою часть проекта.
Постепенно проект начинает разрабатываться, наполняться данными. Это и есть та самая «подводная часть айсберга». А наверху, в видимой части — цифровая модель (3D-модель, информационная модель, модель движения данных). В соответствии с описанной схемой мы выстраиваем все процессы в компании, развиваем информационные технологии. В конечном счете нужно, чтобы любой инженер, занятый в проекте, зайдя в систему, видел свое задание на день, понимал, чтó конкретно он должен сделать, какой документ выпустить и в соответствии с какими требованиями.
Вы сказали, что требования приходят от заказчика. То есть под каждого заказчика все заново нужно выстраивать?
Конечно, должен быть единый стандарт, вне зависимости от того, какой проект мы делаем. Например, по второй очереди Тяньваньской АЭС заказчик не просил нас делать 3D-модель. Но мы уже не можем по-другому выпускать документацию. Наши специалисты уже забыли, что такое Autocad, MicroStation.
Основу для нового стандарта мы как раз сейчас формируем, занимаясь проектом АЭС «Ханхикиви» в Финляндии. У нас уже есть структура, базовая схема движения и обмена данными. В соответствии с требованиями конкретного заказчика мы всегда сможем оперативно уменьшить или увеличить объем информации.
Проектов у вас все больше. А численность персонала остается без изменений?
Мы находимся в балансе между плановыми работами по новым проектам и завершением строительства таких объектов, как Ленинградская АЭС‑2, станция в Белоруссии. Это позволяет нам распределять ресурсы. Постепенно переквалифицируем персонал под европейские нормы, чтобы иметь возможность усилить ресурсами проекты «Ханхикиви» и «Пакш». Также идет постоянный набор новых специалистов. На ближайшие месяцы, например, план по набору — 120 человек.
А где будете брать кадры?
Везде. Мы берем людей с атомных станций, например, операторов БЩУ и РЩУ. Они знают наш проект ВВЭР‑1200, имеют опыт пуско-наладки, ввода в эксплуатацию. Мы их обучаем программным продуктам, системе проектирования, знакомим с организационной схемой. И тут же, как говорится, бросаем в бой.
Удерживаете как? Вдруг обучите — и уйдут в другое место?
У нас достаточно стабильная компания. И ресурсы специфические. В других отраслях наши работники, скорее всего, не смогут использовать все свои знания и умения. Да и такой высокий уровень квалификации мало где востребован — а ведь самореализация для специалиста высокой квалификации — не последняя вещь. Тем не менее система мотивации у нас, безусловно, есть. Она основана на постановке задач: сдать заказчику в конкретную дату качественную документацию, и чтобы заказчик ее принял. Достиг цели — получаешь денежное вознаграждение.
То есть специалист получает деньги за бумагу? А как же экономия стоимости и сокращение сроков строительства?
Система мотивации на снижение стоимости и сроков — это отраслевая программа. А нам не менее важно выпускать качественную документацию точно в срок. Один только финский проект требует огромных усилий всего коллектива с точки зрения концентрации внимания, точности при сборе данных. Когда финны-аудиторы приезжают — они сразу отодвигают в сторону все презентации. Им нужно увидеть наш рабочий процесс
Проект АЭС «Ханхикиви» для вас проблема или вызов?
Как посмотреть. С точки зрения времени и трудозатрат — это, конечно, проблема. С точки зрения развития — это очень полезно. Мы определили несколько основных направлений работы, без которых просто не сможем реализовать этот проект. По ним создали отдельные команды.
Что это за направления?
Прежде всего, это управление требованиями, управление планами качества, работа с оборудованием. То есть атрибутивный состав самой информационной модели.
В проекте выстроена иерархия применения норм, начиная с законов Финляндии, заканчивая законами Евросоюза и российскими нормами.
Еще один вызов — собственно система проектирования. Мы должны четко понимать все траектории движения требований: откуда они пришли — с какого верхнего уровня, как оседают на уровнях ниже, в какие состояния переходят, как отражаются в документах. Полное описание методологии — одно из условий завершения лицензирования по АЭС «Ханхикиви».
Применяете ли вы для управления проектами модные сегодня методы, такие как Agile, Scrum?
На АЭС «Пакш» и на финском проекте мы применяли Agile. Этот метод себя зарекомендовал достаточно хорошо. Мы собирали команды из разных специалистов в одном месте, чтобы за короткое время найти лучшие решения.
Знаете ли вы какой-то пример лучшей практики в построении бизнес-модели проектной компании, которую вы хотели бы внедрить в «Атомпроекте»?
Мы были в Siemens, были в китайских компаниях. Везде своя система. Где-то больше порядка, где-то меньше. Нам понятно, к чему нужно идти. Но зарубежные практики в России скопировать не получится — у нас свои реалии и менталитет.
Когда я был молодым специалистом, меня учили проектировать старшие товарищи. То есть у нас система проектирования реализована на уровне воспитания. А у западных компаний она реализована на уровне процедур. Если в каком-то процессе есть устойчивый навык, но не описана схема, получается, ты в любом месте можешь ошибиться и будет сложно найти ошибку. Четко описанные процедуры уменьшают вероятность ошибки. Мы это хорошо понимаем и активно занимаемся автоматизацией. Машина должна нас проверять. Это сильно экономит время специалистов.
«Атомпроект» внутри отрасли порой сурово критикуют за низкую скорость и высокую стоимость проектов. Как вы относитесь к этой критике?
Смотря какая критика и смотря что именно критикуют. Любая станция строится начиная с заказчика. Это длительный процесс и целая система, и проектный институт — только одна ее часть.
Мы порой не можем сдвинуться с места, потому что не прошли в нужной степени декомпозицию, не поняли, достаточно ли нам данных, не определили окончательно сроки и трудозатраты. Как только мимо какой-то стадии проскочили без нужной степени детализации — сразу появляются проблемы.
Заказчик — то звено, которое выставляет первоначальные требования к проекту. Например, он говорит: «Я хочу 3D». Хорошо. Какая детализация необходима? Как ее оформить? Допустим, заказчик определился: «Хочу, чтобы у вас были дизайн-мануал, система проектирования, все должно быть четко выстроено — покажите мне, как вы проектируете». Хорошо, записали в контракт.
«Хочу, чтобы у вас были процедуры по управлению проектом, по управлению рисками, по управлению изменениями». Наконец он выставил все требования. Все необходимые ИДП от заказчика мы также прописываем в контракте. Теперь нам все понятно, у нас достаточно данных для того, чтобы идти дальше. Мы заключаем договоры со всеми участниками процесса. И начинаем получать ИДП.
Почему сейчас описанная вами система не работает? Тот условный человек, который записывает за заказчиком, он не все записал, не все вопросы задал?
У нас не все декомпозировано до инженера. И инженер вынужден искать свои данные в контракте. Ему надо прочитать тысячи страниц, десятки тысяч требований, — чтобы понять, чтó его касается.
А всего над проектом работает тысяча инженеров. Сколько времени они потратят, чтобы пролистать тысячи страниц? В идеале каждый инженер должен получить ровно тот сгусток информации, который ему нужен, и приступить к работе.
Сколько времени нужно, чтобы выстроить новую систему отношений с заказчиком и достроить бизнес-модель?
У нас сегодня по финскому проекту времени совсем мало. Мы вынуждены все делать на ходу, причем работать по нескольким направлениям параллельно. Проект системы планов качества финскому заказчику уже представлен, есть положительная обратная связь.
А когда вы должны сдать проект полностью?
В июне, крайний срок — осень.
А если не сдадите?
Не можем не сдать. Это даже не вопрос репутации компании. Это задача государственной важности. Мы все это прекрасно понимаем.