Как озадачить консультантов

1718
Неправильно составленное техническое задание на внедрение ERP грозит дополнительными затратами на устранение допущенных ошибок. Как этого избежать финансовому директору

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

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

Трудности перевода

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

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

В качестве другого примера можно привести Задание на проектирование, которое часто составляют в телекоммуникационных компаниях. Это проектная документация, которая оформляется в соответствии со СНИП и проходит государственную экспертизу. Ничего общего с ТЗ она не имеет, но не все компании это понимают. К примеру, на одном из проектов документ, названный «Техническое задание на внедрение ERP», на 80% состоял из описания архитектуры кабельной системы.

На самом же деле правильно составленное ТЗ должно содержать следующие пункты:

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

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

Кто составляет ТЗ

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

|Мнение коллеги|
Алена Бенуа, директор по финансам и информационным технологиям компании «Пробюро»: «Техническое задание мы готовили полгода. На первом этапе мы сформулировали основные требования к системе и провели анализ рынка ERP-систем. В результате выбор был сделан в пользу Microsoft Dynamix AX. После этого был окончательно сформирован список функ-циональных и технических требований. Затем мы провели тендер. На этапе составления технического задания мы практически не взаимодействовали с консультантами, они просто приняли наши требования, на основе которых были определены рамочные условия договора.

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

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

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

ФИНАНСОВОЕ УПРАВЛЕНИЕ ДОЛЖНО УЧАСТВОВАТЬ В СОСТАВЛЕНИИ ТЕХНИЧЕСКОГО ЗАДАНИЯ


Последовательность действий

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

|Мнение специалиста|
Алла Горборукова, заместитель руководителя центра разработки и внедрения ОАО «Волжская ТГК»: «В рамках проекта внедрения информационной системы техническое задание формируется в три последовательных этапа:
1) анализ бизнес-процессов финансового управления, способов взаимодействия со смежными подразделениями (экономическим управлением, управлением по бухгалтерскому учету и отчетности, закупкам, инвестициям и т. д.);
2) подготовка эскизного проекта, в котором описана вся технологическая цепочка, сформулированы задачи, подготовлен перечень имеющихся нормативных документов (положения, регламенты, форматы отчетов);
3) подготовка концептуального проекта (технического задания).

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

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

Шаг 1. Формулировка целей
На этом этапе нужно четко определить, какие цели будут достигнуты за счет внедрения комплексной информационной системы. Очевидно, что никто, кроме менеджмента компании-заказчика, сделать это не в состоянии. Такие цели, как повышение эффективности бизнеса, не принесут успеха проекту автоматизации. Необходимы более конкретные формулировки. Например, «автоматизация процесса бюджетирования в компании».

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

Шаг 2. Определение базовых требований к функциям системы
Другими словами, нужно определить, какими возможностями должна обладать система. Например, необходимость учета затрат на производство, учет оплаты труда, управление материально-техническими ресурсами и т. д.

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

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

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

Одновременно с проведением обследования возможна оптимизация бизнес-процессов.

|Мнение специалиста|
Игорь Кадашев, IT-директор компании «Нидан»: «Техническое задание на внедрение ERP-системы Axapta в компании «Нидан» было сформировано следующим образом. До начала проекта были определены все значимые функциональные требования к системе. Этим занималась команда, в которую входили практически все топ-менеджеры и ключевые специалисты. Требования разрабатывали полтора месяца. Потом мы объявили тендер по выбору системы и уже после этого – тендер по выбору консультанта.

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

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

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

Шаг 4. Выбор решения
Итак, функциональные требования определены, самое время выбрать решение (информационную систему + решение по инфраструктуре) и подрядчика.

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

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

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

Шаг 6. Формирование требований к потребительским характеристикам
Потребительские характеристики – это производительность, надежность, масштабируемость и т. д. В первую очередь этот раздел относится к технической инфраструктуре комплекса. Но от его реализации зависит то, насколько быстро получит пользователь нужный ему отчет, насколько часто система будет недоступна в результате мелких сбоев и на сколько минут либо недель ERP выйдет из строя в случае повреждения оптического канала провайдера. В конце концов, катастрофоустойчивость информационных систем компании напрямую влияет на ее инвестиционную привлекательность. Эти параметры также должны диктоваться компанией. Различные способы реализации могут отличаться по стоимости в десятки раз.

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

Методические рекомендации по управлению финансами компании



Подписка на статьи

Чтобы не пропустить ни одной важной или интересной статьи, подпишитесь на рассылку. Это бесплатно.

Школа

Школа

Проверь свои знания и приобрети новые

Записаться

Самое выгодное предложение

Самое выгодное предложение

Воспользуйтесь самым выгодным предложением на подписку и станьте читателем уже сейчас

Живое общение с редакцией

А еще...


Рассылка



© 2007–2016 ООО «Актион управление и финансы»

«Финансовый директор» — практический журнал по управлению финансами компании

Зарегистрировано Федеральной службой по надзору в сфере связи,
информационных технологий и массовых коммуникаций (Роскомнадзор)
Свидетельство о регистрации Эл №ФС77-43625 от 18.01.2011
Все права защищены. email: fd@fd.ru


  • Мы в соцсетях
×
Чтобы скачать документ, зарегистрируйтесь на сайте!

Это бесплатно и займет всего 1 минуту.

У меня есть пароль
напомнить
Пароль отправлен на почту
Ввести
Я тут впервые
И получить доступ на сайт
Займет минуту!
Введите эл. почту или логин
Неверный логин или пароль
Неверный пароль
Введите пароль
Внимание! Вы читаете профессиональную статью для финансиста.
Зарегистрируйтесь на сайте и продолжите чтение!

Это бесплатно и займет всего 1 минут.

У меня есть пароль
напомнить
Пароль отправлен на почту
Ввести
Я тут впервые
И получить доступ на сайт
Займет минуту!
Введите эл. почту или логин
Неверный логин или пароль
Неверный пароль
Введите пароль