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

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

Причины разногласий

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

Личный опыт

Сергей Сычев, IT-менеджер компании «Талосто» (Санкт-Петербург)

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

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

Евгений Фадеев, директор консалтинговой компании «Дельта Ай Ти» (Ижевск)

Несколько лет назад наша компания внедряла программный комплекс «1С» на предприятии, производящем оружие. Оружие - специфический товар, и за ошибки, допущенные при его учете, предусмотрена уголовная ответственность, поэтому в данном проекте основной задачей была автоматизация учета в полном соответствии с законодательством. И только изучив законодательную базу, мы смогли понять, как данную задачу можно реализовать в системе: какие аналитические срезы необходимы в том или ином отчете, как нужно вести номерной учет оружия и т. п. Впоследствии этот опыт очень пригодился: в 2003 году при автоматизации компаний «Ижевский Арсенал» и «Корнет», специализирующихся на продаже оружия, мы уже могли говорить с оружейниками на одном языке. Востребован этот опыт и сегодня: ведется подготовительная работа по автоматизации отделов сбыта крупнейших ижевских оружейных заводов.

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

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

Пример

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

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

Принципы составления технического задания

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

Совместная работа

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

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

Личный опыт

Сергей Сычев

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

Детальное описание результата

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

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

В общем случае результирующие показатели проекта представляют собой следующее.

Личный опыт

Сергей Сычев

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

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

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

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

Согласование результата

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

Личный опыт

Сергей Кондарев, IT-директор компании «Пальмира ПТ» (Москва)

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

Гибкость

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

Личный опыт

Сергей Сычев

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

Структура технического задания

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

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

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

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