А чего особенного именно в ИСУП?

Если вы приняли решение внедрить систему управления проектами – а особенно, если вы делаете это впервые, то наверняка задаетесь вопросом: как сделать все правильно, минимизировать ошибки, прийти именно к тому результату, который ожидаете?

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

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

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

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

К чему будем стремиться?

Если настройки и обучения мало, то когда в таком случае можно считать внедрение завершенным?

Критерии успешности вашего проекта могут быть сформулированы по-разному (кстати, обязательно их сформулируйте!), но есть одна, на мой взгляд, обязательная цель: все процессы управления проектами выполняются на регулярной основе и с использованием системы.

Это наша программа-минимум. Более сильный критерий – оптимально выстроенные процессы. А вот признаки, по которым можно определить достижение этой цели:

• настроенные процессы способствуют достижению целей компании;

• пользователи принимают систему и регулярно в ней работают;

• задействован необходимый и достаточный набор инструментов.

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

Что может пойти не так?

Помешать может очень многое, не хватит и десятка таких статей, чтобы перечислить возможные ошибки и препятствия. Рассмотрим хотя бы несколько.

Нет опыта внедрения => нет уверенности в результате

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

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

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

Система не отвечает вашим ожиданиям

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

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

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

Появляются новые требования

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

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

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

Но чем масштабнее ваш проект, тем вероятнее, что появятся по-настоящему критичные изменения. На такой случай заложите в ваш проект внедрения резервы – даже если вы не понимаете на старте, как в точности вы их используете.

Ну и, пожалуй, главное: выбирайте гибкую ИСУП, отдавайте предпочтение системам no-code или low-code, в которых цена реализации новых требований гораздо ниже, а процессы зачастую можно перепроектировать непосредственно в системе «на живую». Кроме того, этот класс систем в большей степени приспособлен к итерационному внедрению, когда система запускается максимально быстро, а функциональность наращивается постепенно.

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

Пользователи саботируют систему

Мы уже отметили выше, что вовлечь пользователей в ИСУП несколько сложнее, чем в многие другие информационные системы.

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

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

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

Система заработала, но ее использование стало снижаться

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

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

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

О подходах к внедрению

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

Мы у себя в компании также делим проекты внедрения на два крупных типа (названия их условны и не претендуют на академическую правильность).

Классический проект

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

Такие проекты занимают много времени и достаточно затратны с точки зрения бюджета. Существенную долю трудозатрат (иногда более 50%) поглощает документирование. Внутри этапов часто применяется итерационное планирование, однако общая последовательность этапов фиксирована: нельзя приступить к проектированию, пока не закончено обследование и т.д.

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

Но в тех случаях, когда жестких правил не определено, мы обычно предлагаем идти другим путем.

Итерационное внедрение

Проект делится на типовые функциональные блоки, например, такие:

• сроки и коммуникации (база, без которой не получится стартовать)

• идеи

• риски

• финансы

• ресурсы

• целевые показатели

• предконтрактная деятельность

Блоки запускаются в работу друг за другом, и внутри каждого выполняется такая последовательность работ:

• сбор и обработка данных

• настройка прототипа системы

• обучение пользователей, апробация прототипа

• корректировка и ввод в эксплуатацию

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

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

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

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

Вместо заключения

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

• без внедрения – «не взлетит»;

• двигайтесь постепенно, не пытайтесь объять необъятное;

• больше работайте с людьми – от топ-менеджеров до конечных исполнителей.

Удачи!

Илья Едигарьев

директор департамента реализации проектов ГК ADVANTA