Журнал об электронном контенте, документах и бизнес-процессах
ИТ-директору Делопроизводителю Кадровику Бухгалтеру
Внедрение электронного документооборота

Союз пользователей и ИТ-специалистов: как написать понятное ТЗ на разработку системы

  0 комментариев Добавить в закладки

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

Если требования пишет только пользователь

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

При этом поставщик в любом случае не сможет закрыть все требования коробочной функциональностью системы. И вынужден будет либо потратить время (своё и заказчика) на согласование ограничений, либо оценить стоимость реализации ТЗ в полном объёме, что увеличит бюджет в несколько раз.

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

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

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

Если пишут только ИТ-специалисты

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

ИТ-специалистам, продвигающим инициативу внедрения нового ПО, важны:

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

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

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

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

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

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

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

Рекомендации

Чтобы получить качественную оценку проекта, при составлении ТЗ:

  1. Сосредоточьтесь на том, что важно сделать в рамках текущего проекта. Для глобальных планов существуют отдельные документы, например, концепция автоматизации.
  2. Описывайте потребности пользователей, а не проектные решения. Каждая система уникальна, и задача поставщика – предложить вам наиболее эффективное решение на базе своих продуктов.
  3. Зафиксируйте основных участников и этапы процессов, перечислите виды документов. Понимание специфики работы в вашей компании позволит оптимально оценить их масштабы.
  4. Составляйте требования вместе с пользователями и ИТ-специалистами. Так вы минимизируете число неучтённых требований и обеспечите максимально эффективное использование бюджетов.
Ещё материалы автора
Похожие записи
Комментарии (0)
Сейчас обсуждают
Больше комментариев