Обретение компетенций

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

Подготовка внутренних специалистов является самым очевидным, но от этого не менее проблематичным подходом. Во-первых, консультанты далеко не всегда с радостью делятся своими профессиональными секретами. Как показало исследование «Удовлетворенность клиентов сотрудничеством со сторонними ИТ-интеграторами», проведенное Headwork Analytics при поддержке журнала «Директор информационной службы» (CIO.ru), проблемы при взаимодействии с консультантами действительно нередки. Тем не менее компании вынуждены использовать услуги интеграторов — прежде всего, из-за нехватки внутренней компетенции и дефицита квалифицированных специалистов.

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

Опыт — сын ошибок трудных

«Это одна из больных тем для многих ИТ-руководителей. Иногда знания утекают из компании буквально сквозь пальцы, что крайне обидно», — отмечает Нестор Комарницкий, директор департамента ИТ Group DF International Ukraine.

Стоит отметить, что передача знаний является неотъемлемой частью процесса консалтинга. Если она отсутствует, с большой вероятностью будет неудовлетворительным и результат проекта, ради которого клиент и обратился к консультанту. Поэтому задача состоит в том, чтобы проект не просто осуществился, но и чтобы у него было будущее.

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

Прежде чем обязывать собственных специалистов перенимать знания, важно осознать причины появления на горизонте консультантов. Обычно таких причин может быть три: полное отсутствие ресурсов и компетенций; наличие ресурсов, но отсутствие доверия к ним; необходимость формального участия — «благословения» со стороны консультантов проекта, выполняемого собственными ресурсами. В зависимости от причин необходимо выстраивать работу с сотрудниками.

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

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

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

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

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

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

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

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

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

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

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

«Зачастую подрядчики «подсаживают» компанию на свои услуги — оставляют в системах «черные ящики», знания о которых есть только у них», Дмитрий Болотюк, директор департамента ИТ группы «Росводоканал»

Проверка в боевых условиях

«Зачастую подрядчики «подсаживают» компанию на свои услуги — оставляют в системах «черные ящики», знания о которых есть только у них, — делится опытом Дмитрий Болотюк, директор департамента ИТ группы «Росводоканал». — С такой проблемой мы столкнулись в ходе нескольких проектов».

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

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

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

Если обучение построено грамотно, то в течение года-полутора (столько длится типичное внедрение системы ERP на крупном предприятии) сотрудник вполне может освоить все тонкости системы. Весь вопрос в мотивации и наличии у специалиста цели — человек должен понимать, что по окончании проекта он один или в составе группы сотрудников будет сопровождать систему.

Бывают и нестандартные решения. Например, в ходе проекта SAP «Росводоканал» предложил подрядчику выделить консультанта, которого обязался по окончании проекта взять на работу. Этот вариант сработал, и риски были значительно сокращены. Сейчас этот консультант в одиночку сопровождает созданную систему.

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

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

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

Именно поэтому в перечне результатов выполняемых в рамках проекта работ обязательно должна быть указана документация — результаты должны быть осязаемыми. Скажем, если была выполнена доработка системы, то в число документов должны входить описание доработок и инструкции пользователей. Это позволяет не просто минимизировать количество «черных ящиков», подвластных лишь консультантам. При наличии качественной документации даже новые специалисты, пришедшие в проект, смогут быстрее разобраться в особенностях решения.

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

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

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

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

Компании ищут компетенции

Диаграммы

 

Как показало исследование, проведенное Headwork Analytics при поддержке журнала «Директор информационной службы» (CIO.ru), компании используют услуги интеграторов прежде всего из-за дефицита квалифицированных специалистов и нехватки внутренней компетенции. При этом они считают, что риски от привлечения внешних ресурсов такие же, как и при реализации работ собственными силами (а если и выше, то незначительно).

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

Что любопытно, как заявили почти в четверти компаний, у них не было никаких проблем при взаимодействии с поставщиком услуг.

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

75% компаний считают свой опыт взаимодействия с интеграторами в целом успешным. Только 1% проектов был полностью провален. Причинами абсолютных неудач стало непонимание подрядчиком бизнес-процессов заказчика и отсутствие у него ответственности за результат. Самый высокий процент провальных проектов приходится на ИТ-консалтинг и внедрение интеграционных решений.