Фазы внедрения проекта и их относительная продолжительность:

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

Анализ ROI позволяет клиентам:

• определить точный план и сформировать бюджет;

• оценить рентабельность инвестиций (ROI): выгоды по сравнению с затратами;

• пересмотреть свои требования к программному обеспечению;

• развеять свои сомнения относительно осуществимости проекта и сформировать команду.

Руководитель проекта предоставляет:

• анализ экономии и выгод для клиента (Returns);

• бюджет и план реализации (Investments);

• соответствие между потребностями бизнеса и функциями продукта;

• демонстрация ключевых бизнес-процессов (POC);

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

POC (Proof of Concept): Это демонстрации или презентации, которые показывают, как определенные функции или процессы могут быть реализованы в системе. Они помогают ключевым пользователям понять, как новая система будет работать в реальных условиях.

Этапы анализа:

1. Встреча с заинтересованными сторонами: установите ожидания и определите цели, мотивацию и риски в ходе стартового совещания по ROI (см. приложение A).

2. Покажите мне, как вы работаете («as is»): поработайте с одним ключевым пользователем из каждого отдела, чтобы понять, как они работают в настоящее время:

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

• определите текущие болевые точки (pain points);

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

3. Семинары «Как должно быть» («to be»):

• покажите, что должно быть сделано, на основе демонстраций POC;

• определите болевые точки (pain points), пробелы (gaps);

• заполните вкладку «Returns»: определите, как люди тратят свое время в каждом отделе.

4. Проведение независимой оценки экспертами Odoo и разработчиками для оспаривания предложенных решений.

5. Представление результатов клиенту, используя презентацию закрытия ROI (см. приложение D), и проведите демонстрацию продукта (или макеты, если вы не смогли настроить демонстрационную версию).

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

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

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

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

Советы по анализу (Analysis Tips):

• действуйте как продавец, ведь проект ещё не утвержден! На этом этапе ваша задача – успокоить людей и заинтересовать их. Покажите им ключевые функции системы в действии;

• во время анализа текущего состояния («Как есть») делайте как можно больше скриншотов или записей экрана их текущего решения, а также распечатывайте образцы отчетов и данных;

• после того как ключевые пользователи проекта будут уверены в успехе проекта, оцените, как люди тратят свое время (например, X% на это, Y% на то); это ключевой элемент для оценки потенциальной доходности;

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

• определите болевые точки ключевых пользователей (key-users’ pain points). Используйте шаблон анализа ROI, чтобы получить идеи о наиболее распространенных болевых точках в каждом отделе; 

• найдите решения для каждой проблемы, стараясь придерживаться стандартных решений, насколько это возможно. Не обязательно выполнять все запросы ключевых пользователей, их требования должны быть обоснованы;

• никогда не представляйте клиенту несколько вариантов: как руководитель проекта, вы должны предложить лучший вариант и принимать решения самостоятельно. Роль клиента – оспаривать ваши предложения, а не решать, что делать.

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

• предоставьте общую картину: заинтересованные стороны предоставят вам ключевые цели и/или проблемы на раннем этапе. Ваша задача – представить согласованное решение, учитывающее основные проблемы руководства и обеспечивающее принятие системы конечными пользователями.

После интервью:

1. Проведите внешний аудит (peer-review) с экспертом Odoo, который не участвует в проекте напрямую. Такой эксперт не подвержен влиянию клиента и может принимать независимые решения, а также давать критические замечания.

2. Цель независимой оценки:

• оценить, действительно ли необходима разработка под заказ, и если да, то расставить приоритеты, чтобы сократить бюджет и сроки;

• проверить, не упустили ли вы ключевые болевые точки в соответствующей отрасли;

• оценить качество анализа и общую осуществимость и согласованность предлагаемого решения.

3. Все необходимые разработки должны быть разделены на две категории:

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

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

По завершению анализа:

• подведите итог вашему анализу (функциональное и бизнес-покрытие, требуемые ресурсы с обеих сторон, планирование и риски);

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

Для успеха проекта, нам необходимо обеспечить полную вовлеченность и поддержку всех сотрудников компании. Именно для этого проводится стартовая встреча (Project Kick-Off). Необходимо создать заинтересованность внутри компании клиента, управлять ожиданиями, заставить их согласиться с нашим подходом и, прежде всего, создать надежный план реализации!

Вы должны понимать, насколько важен этот шаг. Успех всего проекта зависит от того, как вы его проведете. Именно поэтому вы потратите на него не менее 10% времени проекта.

Цели стартового совещания (Kick-Off) заключаются в следующем:

• ознакомить SPoC (ключевое контактное лицо) с методологией и согласовать общее видение;

• провести экспресс-анализ ROI для подтверждения реализуемости проекта (если это еще не сделано);

• завершить разработку плана проекта;

• вовлечь SPoC и убедиться, что он выделяет время на изучение Odoo;

• ознакомить проектную команду заказчика со стратегией внедрения изменений.

«У меня был проект по внедрению Odoo для компании Inproma, занимающейся дистрибуцией фирменных товаров. Мне однажды поручили проект под названием «Electronics123». Сообщение от продавца было примерно такое: «Этот клиент АБСОЛЮТНО НУЖДАЕТСЯ в том, чтобы его системы Управления складом, Производством, Закупками, Управлением продажами и Веб-сайтом/Электронной коммерцией были запущены и работали через 2 недели. Его контракт с Netsuite заканчивается тогда, и он останется без системы».

У меня было всего 12 календарных дней, для полного внедрения ERP.

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

1. Мы идем полностью по стандарту;

2. Вы делаете то, что я говорю, и не задаете вопросов, потому что у меня не будет времени объяснять каждое решение, которое я принимаю». Он согласился.

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

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

– Лоренс, руководитель проекта, Odoo SF

Советы по старту проекта (Kick-Off Tips):

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

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

• уделите время обучению SPoC (ключевого контактного лица): познакомьте его с платформой eLearning, документацией и обучите ключевым бизнес-процессам. Без глубокого знания продукта он не сможет эффективно выполнять свою роль;

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

У меня есть два примера, иллюстрирующие важность соблюдения этих правил.

Случай 1: Неудачное внедрение

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

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

В итоге проект затянулся на несколько месяцев, и уровень удовлетворенности клиента оставляет желать лучшего.

Случай 2: Успешное внедрение

В другом проекте я действовал иначе: я сразу обозначил границы. Я объяснил клиенту, что буду отклонять любые запросы на доработки, если они не обоснованы как «must have» и для них нет стандартных альтернатив.

Это изменило все. Клиент стал открыт к моим предложениям, и мы сэкономили 100 часов разработки, используя стандартные решения.

– Одрик, руководитель проекта, Odoo BE

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

После этапа запуска проекта (Kick-Off) разработанное решение было продемонстрировано ключевым пользователям. Теперь пришло время воплотить его в жизнь!

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

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

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

Миграция данных из текущей системы в Odoo может привести к задержкам и требует принятия верных решений:

• не откладывайте внедрение из-за качества данных: Импорт максимально очищенных данных предпочтителен, но не ценой переносов сроков проекта. Если клиент не подготовил данные вовремя и уже использует их в текущем состоянии, не переносите срок запуска ради их очистки. Изменить данные можно в Odoo уже после ввода системы в эксплуатацию;

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

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

На этом этапе Руководитель проекта утверждает, что именно должно быть разработано, обычно это то, что необходимо для ведения бизнеса, а не то, что является просто «приятным дополнением» (без этого можно обойтись, но это не идеально).

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

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

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

Как только все требования определенного этапа выполнены, SPoC проводит финальные тесты и дает «зеленый свет» для запуска системы в эксплуатацию. Как внутренние эксперты по Odoo, SPoC и/или ключевые пользователи организуют и проводят обучение всех конечных пользователей.

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

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

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

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

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

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

4. Не делайте то, в чем вы не уверены. Обещания менеджера по продажам можно пересмотреть. Договор менее важен, чем успех проекта. Вы всегда можете убедить генерального директора не внедрять идею (даже если она была указана в первоначальном договоре).

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

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

Классический путь внедрения

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

1. База данных не полностью протестирована: убедитесь, что ключевые пользователи проверили все бизнес-процессы.

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

1. Обучение — это не лекции. Поощряйте SPoC, чтобы ключевые пользователи самостоятельно выполняли процессы под их руководством.

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

3. Создайте положительный настрой. Успешное принятие системы пользователями достигается через то, чтобы запуск стал чем-то ожидаемым, а лучше — таким, которого они с нетерпением ждут и хотят опробовать на практике.

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

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

6. Находитесь на месте первые дни развертывания, если среди пользователей есть сопротивление изменениям. Вы сможете их поддерживать и помогать.

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

Классический путь запуска и сопровождения

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

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

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

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

Как я могу помочь сотрудникам своего клиента делать больше за меньшее время?

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

Пример матрицы цифровых возможностей

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

• избегать (To avoid) – низкий потенциальный эффект и высокая сложность реализации: такие инициативы не принесут существенной пользы;

• тонкая настройка (Fine tuning) – низкий потенциальный эффект, но простая реализация: эти инициативы не являются приоритетными, но их можно рассмотреть в будущем;

• прорывные изменения (Game changers) – высокий потенциальный эффект, но сложность реализации: такие инициативы способны кардинально улучшить положение компании;

• быстрые победы (Quick wins) – главный приоритет, так как они обеспечивают быстрые и значительные улучшения.

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

• цель, как и в анализе ROI, – найти способы сэкономить время сотрудников в их повседневных задачах;

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

• простота и ясность: Лучше включить 3 важных пункта, чем 10 посредственных;

• начинайте писать отчет с первого дня: Внимательно наблюдайте за процессом внедрения и фиксируйте возможности для улучшений внутри компании;

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

Алексис в день запуска системы Первое судно зашло в терминал

Проект в компании, занимающейся предоставлением услуг по навигации