Предпроектные работы: описание фазы анализа (инструкция для консультанта)

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

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

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

  • К каким результатам должен привести проект? Что было обещано / обсуждалось на встречах, предшествующих соглашению о продаже?
  • Какие вопросы остались открытыми и требуют рассмотрения для успешной реализации проекта? Есть ли «зыбкие» моменты, требующие осторожности?
  • Какие еще возможности имеются у клиента?

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

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

Категории проектов:

  • Крупные: > 30 оплачиваемых дней
  • Средние: от 5 до 30 оплачиваемых дней
  • Мелкие: < 5 оплачиваемых дней и проекты с посуточной оплатой

Заявление об обязательствах

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

Сметно-финансовые расчеты

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

Технические требования

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

Сдерживающие факторы

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

Самое важное состоит в том, что если требования к проекту четко не определены, это придется делать позднее в процессе внедрения, обычно уже после того, как клиентом затрачено много времени и средств. К сожалению, многие проекты не удаются из-за неполного понимания требований, и слишком часто действует закон Мескимена: "Никогда не бывает времени сделать правильно, но всегда есть время сделать заново".

Анализ рабочих требований

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

  • Какова существующая система (процесс) отчетности и анализа? Имеются ли схемы, описывающие процесс? Требует ли он большого количества ручной работы?
  • Каким видится предлагаемое решение? Необходимо собрать достаточно информации, чтобы можно было сделать графическое представление предлагаемого решения и сопрягаемых приложений / источников данных.
  • Каковы конечные цели проекта? Как будет определяться степень его успеха?
  • Какова стратегия внедрения? Предполагается ли наличие нескольких этапов реализации проекта? Какие это этапы? Что находится в пределах и за пределами каждого из них?
  • Кто должен работать в команде и какие для этого требуются навыки? Сколько времени смогут соответствующие сотрудники уделить проекту? Какие существуют пробелы в квалификации или кадрах и как они будут восполнены?
  • На каких посылках основываются предпринимаемые действия?

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

Анализ технических требований

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

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

Конкретные цели встречи/совещания:

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

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

 

Вопросы и ответы по автоматизированным системам

  • Как классифицировать проекты внедрения автоматизированных систем? +

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

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

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

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

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