Статьи

Предпроектное обследование - быть или не быть?

Обследование — что это?

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

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

Для полноты картины перечислим все этапы работ, рекомендуемые методологией внедрения программного обеспечения (ПО):

  1. Обследование,
  2. Адаптация ПО,
  3. Наполнение базы данных первоначальными данными,
  4. Обучение пользователей,
  5. Опытная эксплуатация,
  6. Ввод в промышленную эксплуатацию.

Обращаю ваше внимание на то, что п.п. 2‒4 могут идти параллельно и/или следовать в произвольном порядке.

В терминах PMBOK® перечисленные пункты называются «Содержанием проекта», (естественно, автор здесь не претендует на точное отражение свода знаний PMBOK® и допускает некоторые вольности речи, которые для целей данной статьи считает вполне оправданными).

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

Адаптация ПО.

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

Наполнение базы данных…

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

Обучение пользователей.

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

Опытная эксплуатация.

На данном этапе необходимо проверить функционирование новой автоматизированной системы в условиях «близким к боевым». Ввод в промышленную эксплуатацию.

Завершающий этап проекта,

результат — ПО внедрено и все поставленные проблемы решены.

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

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

    Однако главная задача обследования состоит в другом. Вспомним, что цель любого проекта — это решение какой-либо проблемы заказчика (иначе не понятно, зачем заказчик затеял дорогостоящие процедуры). Но дело в том, что исполнитель не решает проблему, а совершает некий комплекс работ направленный на решение данной проблемы. Если работы были спланированы правильно и выполнены с приемлемым качеством, то проблема будет решена, в противном случае — как повезет. Проще говоря, исполнитель хочет получить деньги за выполненные работы и не выполнять бесплатные работы. Заказчик же готов платить за решение проблемы и не хочет порождения новых проблем. Налицо, некий конфликт интересов. Решается он совместной работой исполнителя и заказчика. Результатом этой работы будет совместно выработанный путь по достижению цели. Сам результат фиксируется в документе, обычно называемым «Отчетом об обследовании», который в дальнейшем будет основанием для проведения проектных работ. Именно на этапе обследования абстрактная цель («Автоматизируйте мне учет» или «Внедрите CRM») превращается в комплекс четких задач.

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

    Скажу несколько слов об «Отчете об обследовании». Он состоит из двух частей:

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

    Приведем примеры возможных работ:

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

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

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

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

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

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

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

        Перечислим еще ряд целей, которые достигаются обследованием.

        К ним можно отнести решение проблемы: «а верно ли исполнитель понимает заказчика, говорят ли они на одном языке?». Исполнитель с заказчиком могут использовать одни и те же термины, но в разных значениях. Особенно это проявляется в производственных областях, где термин спецификация может означать, что угодно. Именно по этому иногда происходит удорожание или удешевление проекта Заказчик хотел автоматизировать бюджетирование, но процессе обследования может выясниться, что под бюджетированием он понимал, не только долгосрочное финансовое планирование, но и казначейство (краткосрочное планирование движения денежных средств) — это увеличит стоимость проекта, а фактически изменит проект. Могут быть и обратные случаи, когда исполнитель предполагал какие-либо работы, но в процессе обследования, выяснилось, что они не нужны.

        Как проходит обследование?

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

        Этот процесс может повторяться несколько раз. Когда информация собрана и обработана, результат оформляется в виде «Отчета об обследовании», затем утверждается.

        Как быть с нюансами?

        Если взять проект по постройке дома, то, как бы мы не спускались вниз по чертежам, мы всегда будем встречать подробное описание изделий, все материалы будут иметь ГОСТ, везде будут инструкции, вплоть до описаний условий проведения работ. В IT-сфере в массе своей документация не разработана или закрыта. Фактически «Отчет об обследовании» является единственным документом, описывающем все проектные работы (иногда его разбивают на части и дают им различные названия). Возникает вопрос: А насколько он должен быть подробен? Очевиден ответ: Он должен быть очень подробен, и не допускать двояких толкований! Но…

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

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

        Левин С.В., руководитель проектов компании «ИнтКом Альянс»
        Опубликовано на Audit-it.ru

        Отзыв о внедрении программного комплекса «1С:Управление производственным предприятием для Украины 8» в компании «Лукойл» (Одесса) Отзыв о внедрении регламентированного и бухгалтерского учета в компании «Винфорт» (Киев, Одесса) Отзыв о проекте IT-аудита в компании «Олдi» (Киев, Донецк, Житомир, Днепропетровск, Симферополь) Отзыв о проекте комплексной автоматизации в компании «Виола» (Запорожье) Отзыв о внедрении проекта комплексной автоматизации в компании «Пласке» (Одесса) Отзыв о внедрении проекта комплексной автоматизации в компании «Солнечная долина» (Одесса) Отзыв о внедрении программного комплекса «1С:Управление торговлей для Украины 8» в компании «Тумен» (Одесса) Отзыв о внедрении проекта автоматизации оперативного учета в компании «Эста Холдинг» (Донецк, Киев) Отзыв по обучению работе в программном комплексе ABIS-ISO сотрудников «Таврия-В» (Киев, Одесса, Николаев, Харьков, Львов и пр.)