Есть три стратегии внедрения:

Рассмотрим отдельно каждую из стратегий, оценим их преимущества и недостатки.

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

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

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

В чем недостатки такой стратегии?

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

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

Поэтому максимально важно грамотно поставить бизнес-цели — именно к ним мы будем апеллировать в случае каких-либо отклонений или когда возникнет потребность в приоритизации требований.

3. Очень часто мы внедряем ИСУП как IT-проект, то есть привлекаем подрядчика, который только настраивает программу, обучает сотрудников использованию системы и устраняет баги. В его полномочия не входят вопросы приживаемости (проведение ретроспективы, сбор обратной связи и т. д.). Эта часть остается на стороне исполнителя, который часто либо не понимает важности этого аспекта, либо не обладает нужной экспертизой, либо не располагает необходимым бюджетом.

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

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

4. Методологические решения мы вынуждены принимать по ходу дела. И в связи с этим возникает много вопросов, например: что включает в себя объектная модель? что для вас значит программа и чем она отличается от проекта? что в себя включает жизненный цикл? Если проект направлен только на разработку и внедрение ИСУП, от него и не ожидается разработки методологии, на это не выделяется бюджет, в команде внедрения нет экспертов-методологов. Поэтому такие вопросы если и разрешаются, то практически «на коленке».

5. Также немалые риски связаны с прохождением внутренней системы контролей — на соответствие ИТ-архитектуре, требованиям по информационной безопасности, требованиям закупок и т. д. Эти корпоративные реалии, к сожалению, не позволяют сделать что-то работающее “quick&dirty” (быстро создать черновой работающий вариант) и принести пользу с помощью рабочего инструмента в короткий срок.

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

Один из идеальных алгоритмов, которые можно считать компромиссными и для грамотного подрядчика, и для клиента: первичное проведение хэлф-чека (своего рода аудита или оценки зрелости) проектной деятельности, проектирование необходимых организационных изменений и только потом — разработка и внедрение ИСУП. Такой подход поможет компании избежать «автоматизации бардака».

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

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

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

В чем недостатки такой стратегии?

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

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

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

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

Самый оптимальный вариант, однако тоже со своими недостатками, — это параллельное внедрение. Этот вариант медленнее, чем первый, однако заметно более эффективный.

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

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

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

В чем недостатки такой стратегии?

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

2. Методологические решения будут более медленными и тяжелыми в согласовании, чем IT-решения. Это приведет к тому, что, когда решения уже будут согласованы, придется переделывать IT-систему (поскольку, скорее всего, для ее первичной разработки мы будем основываться на временных решениях).

3. Если мы сразу двигаемся по пути параллельной стратегии, это сильно дороже, и бюджет труднее обосновать. Поэтому вполне возможно, что сначала придется пожертвовать каким-то направлением работы, чтобы доказать эффективность проекта и подхода и получить всё необходимое финансирование.

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

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

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

Начинать с методологии в нынешних реалиях, если предполагается последующее скорое внедрение ИСУП, на мой взгляд, не имеет смысла.