Предпроектное обследование перед проектом внедрения 1С

Наши клиенты обычно опасаются следующего:

1. Недостаточные компетенции у команды Исполнителя. Специалисты не владеющие предметной областью и(или) не обладающие техническими навыками вряд ли выполнят проект в согласованные сроки. В таких случаях Исполнителем часто дается заниженная оценка сроков и стоимости, опять же связанная с недостатком опыта. Заказчик выбравший предложение с ценой значительно ниже среднего часто встречает именно таких Исполнителей.
2. Недостаточное количество специалистов выделенное на проект. Объем проекта и сроки реализации проекта часто требуют подключения большого количества специалистов, особенно на ключевых этапах, таких как запуск в промышленную эксплуатацию. Если на этапе планирования на это не выделены ресурсы, велик риск срыва запуска и бесконечных авралов. 
3. Неспособность руководителя проекта управлять проектом. Этот риск может не сыграть, если у заказчика опытный РП, обладающий запасом свободного времени.

Мы как исполнители также видим ряд рисков

1. Неадекватные/противоречивые требования у заказчика. В перспективе это приводит к потере интереса к проекту со стороны заказчика.
2. Недостаточное количество специалистов клиента, выделенное на проект. Это приводит к затягиванию сроков согласования документов и проверки результатов. За время простоя команда исполнителя вынуждено переключается на другие проекты и проект замораживается.
3. Неспособность руководителя проекта со стороны заказчика управлять проектом. Недостаточные полномочия РП приводят к тому, что проект буксует и останавливается на любых взаимодействиях – от назначениях встреч с ключевыми пользователями, до подписания актов.

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

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

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

Предпроект по шагам

Как и любой (мини)проект, предпроект имеет все соответствующие атрибуты: сроки, цели, команду и т.д. О проектах в целом написано уже много, поэтому сфокусируемся именно на предпроекте. Стандартные шаги (пред)проекта – это типовая информация об этапах любого проекта. Её можно пропустить истинным ценителям руководителям проектов.

Подписываем договор и NDA

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

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

Создаем и подписываем Устав

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

Устав освещает следующие основные вопросы:

• Цели (пред)проекта. Четко определяются основные цели и ожидаемые результаты проекта.
• Область деятельности. Описывается сфера деятельности проекта, его организационный охват и границы.
• Роли и ответственность. Определяются роли и обязанности участников проекта, включая команду проекта, заинтересованные стороны и других участников.
• План работы. Составляется общий план работы, включающий этапы проекта, ключевые моменты, контрольные точки и сроки выполнения.
• Ресурсы. Определяются требуемые ресурсы, такие как финансы, персонал, оборудование, материалы и т.д.
• Ограничения. Указываются ограничения, которые необходимо учесть при планировании проекта. Например, бюджетные ограничения, временные рамки, ресурсные ограничения и другие факторы, которые могут повлиять на план и выполнение проекта.
• Проектные риски. Производится анализ возможных рисков, связанных с проектом, определяются стратегии и план управления ими.

После подписания устава РП готовит карту процессов заказчика верхнего уровня. Основной исполнитель этого этапа  – Аналитик. Аналитик составляет список функциональных областей для обследования. Далее запрашивает у заказчика ответственных сотрудников по этим областям. Список сотрудников (Ключевых пользователей) предоставляет заказчик.

Согласовываем план интервью

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

Как проходит интервью?

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

Аналитик задает вопросы по заранее подготовленным опросникам, четко следуя регламенту и таймингу встречи.

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

После прохождения интервью идут следующие блоки работ:

• согласование результатов интервью 
• анализ предоставленных документов (методики, регламенты, инструкции)
• анализ текущей системы автоматизации
• подготовка отчета об обследовании (в случае если говорим о внедрении, то этот документ называется Концепция АСУ),
• презентация результатов обследования заказчику

Схема предпроектного обследования

Результаты предпроекта 1С

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

Основными выходными документами предпроекта являются:

Отчет об обследовании /концепция.

Содержит:

• Структурированные, непротиворечивые, функциональные требования к будущей информационной системе. *Страхует проект от выполнения неточных или противоречивых требований.
• Ссылки на важные печатные формы, отчеты и регламенты, которые необходимо будет использовать на будущих этапах. *Гарантирует что внешний вид выходных документов не станет сюрпризом для заказчика. 
• Специфику ведения учета конкретного заказчика, по которому можно сделать заключение, какой типовой продукт наиболее соответствует бизнес-процессам. *Позволяет руководителю проекта со стороны заказчика на собрании совета директоров не только стукнуть по столу и крикнуть “Внедряем ERP”, но и привести несколько аргументов в защиту своей позиции.
• Перечень улучшений, которые клиент мог бы внедрить за рамками совместного проекта. *Делит функциональные требования на до и после проекта.
• Перечень организационных изменений, которые заказчик должен реализовать, чтобы 1С запустилась. *Страхует от патовой ситуации в разгаре проекта под названием “ваш бизнес не готов к такой автоматизации”.
• Предлагаемую IT-инфраструктуру, выбранные типовые продукты и схему обменов. *А тут мы получаем письменное одобрение от ИТ службы, что они готовы сотрудничать и не будут занудами на следующих этапах проекта.
• Обезличенное описание процессов «as is» (опционально, необходимость уточняется на этапе согласования договора) *Честно говоря, наши заказчики часто отказываются от этой опции. Скромно говорят, что нечего тратить время(исполнителя) и  деньги(заказчика) и  описывать хаос. Но иногда руководители все же просят такое описание, видимо для отчета о масштабе планируемых изменений и улучшений.

Анкеты по итогам интервью (согласованные с респондентами) *Написано пером, не вырубишь топором, слово не воробей, вылетит не поймаешь.

Бюджет,  укрупненный план-график работ всего проекта. *Этот раздел важен для планирования денег. Шутки тут неуместны. Знание о сроках и стоимости проекта до начала работ еще никому не мешало.

Если смотреть с позиции решаемых задач, то по итогам предпроекта заказчик получает:

• Зафиксированные цели проекта, выявленные и описанные требования пользователей к автоматизированной системе, разработанные требования к ИТ-инфраструктуре, риски проекта, план работ по проекту, описанные ограничения проекта, зафиксированные роли ключевых пользователей заказчика.
• Достаточное количество информации для оптимального и обоснованного выбора комплекса IT систем, разработки модели прохождения бизнес-процессов в системе 
• Перечень изменений, решений, действий, которые нужно сделать, чтобы 1С «взлетела».
• Опыт совместного проектирования системы в команде с исполнителем. *Важность этого опыта трудно переоценить. Сработанная команда имеет гораздо бОльшие шансы выполнить проект.
• Рекомендации по улучшению бизнеса, обнаруженные командой Исполнителя, как сторонними наблюдателями, которые не погружены в этот бизнес, но видели много схожих бизнес-процессов в других компаниях. *Нет гарантий, что такие рекомендации будут, но обычно по итогам предпроекта мы приносим заказчику несколько “фишек” касающихся его бизнес-процессов. 

Стоимость предпроектного обследования 1С

Стоимость предпроекта зависит от нескольких показателей:

• количество ключевых лиц, с которыми проводится интервью; *Прямая зависимость с ценой
• количество процессов, входящих в границы проекта; *Защита от ситуации  – “ой у нас 1 человек все знает, давай одного интервьюировать”
• сроки выделенные заказчиком на проведение предпроекта; *Обратная зависимость с ценой –  меньше сроки, больше стоимость.
• наличие опыта у Исполнителя в сфере деятельности Заказчика. *Мы обычно делаем профильные для нас проекты. Если вдруг тема для нас новая – заранее предупреждаем и обсуждаем цену с учетом того, что мы тоже учимся.

Нормальной практикой является проведение предпроекта в короткие сроки (от 2 недель до 3 месяцев в зависимости от масштаба проекта). Стоимость фиксированная и согласовывается в договоре до начала работ.

Выводы

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

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

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

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

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

1. Договориться о проекте. Цели, cроки, стоимость, команды, рамки и т.д. Именно эти конкретные договоренности позволят в будущем вести команду проекта к ожидаемому результату. Здесь же создаются договоренности о взаимных требованиях. При возникновении спорных ситуаций в ходе проекта удобно обращаться к заранее согласованным правилам игры. Большая часть этих правил отражается в договоре на выполнение работ и Уставе проекта.
2. Уточнить детали. Формализация требований к основному проекту, таким образом, чтобы они были конкретны и одинаково понятны и заказчику и Исполнителю. Далеко не всегда заказчик в состоянии четко сформулировать свои требования более развернуто, чем “хочу, чтобы все работало автоматически”. Более того, в различных подразделениях компании могут быть разные требования к процессу, который подлежит автоматизации. Знать это до того, как проект стартовал, а значит существенно снизить проектные риски.
3. Познакомить  проектные команды заказчика и исполнителя. Опыт совместной работы, полученный на предпроекте значительно снижает риски на основном проекте. Любой проект автоматизации делают люди. Они программируют, консультируют и управляют проектом. От того насколько эффективно выстроена совместная работа зависит общий итог проекта, причем степень этой зависимости трудно переоценить. Бизнес это вообще командная игра – недаром топ менеджеры переходят как правило со своей командой. Как и в спорте выдающихся результатов достигают команды, которые успешно между собой взаимодействуют, дополняют друг друга и сотрудничают. И вот ИТ проект рождает новую команду из сотрудников заказчика и исполнителя. Но готовы ли эти люди работать вместе? К сожалению, ответ на этот вопрос заранее неизвестен. Только реальный опыт взаимодействия проявляет сильные и слабые стороны новой команды. И именно этот опыт можно получить выполнив предпроектное обследование.