Введение

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

Примечание. Мы понимаем что есть еще стандарты на ТЗ от IEEE, ISO и пр. Однако с чего-то же нужно начинать ;-) Мы в Аксиан) придерживаемся свободных взглядов на ТЗ — главное использовать в нем общий с Заказчиком язык.,
 

Общие положения

Первоначально мы предполагали создать только унифицированный чек-лист на тему «Порядок подготовки технического задания на внедрение информационной системы», однако быстро понял, что сделав документ похожим на задание по ЕГ, мы получим результат столь же полезный для финансового директора, как и результаты ЕГ для оценки знаний. Изменив подход, предлагаем вашему вниманию некий алгоритм работы над техническим заданием, с пояснениями, почему мы выполняем то или иное действие. Мы считаем, что руководитель должен делать все действия осознанно, чтобы понимать их последствия. «ЕГ»-шный «чек-лист» не дает такого результата. Тем не менее, ниже вы найдете формальный чек-лист для проверки полноты технического задания, разработанный на базе ГОСТ 34.602-89 и ГОСТ 19.201-78.
Замечание.Формальный — потому что маловероятно, что финансовый директор обладает всей полнотой технических знаний и располагает временем для проверки содержательной части ТЗ.

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

С информационными системами на этом моменте понимания происходит путаница: ИС, как правило, создаются для внесения инноваций, модернизации, изменения существующего положения вещей, но при этом участники проекта по внедрению ИС пытаются ее «встраивать» в существующие алгоритмы. Происходит разрыв декларируемых и фактических целей и Заказчик получает не то, что ожидал. Чтобы желаемое не расходилось с действительным важно максимально полно описать «желаемое» в техническом задании.
Присутствие «магических» терминов — «информационная система», «виртуальный» и т. п. не переводит задачу в область эфемерных, высоких материй. Всё также происходит в материальном мире — выполняется и контролируется людьми.
Прежде всего, необходимо определиться с двумя основными вводными фактами:
 

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

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

Техническое задание на внедрение информационной системы

Сценарий 1

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

1. Назначить ответственного в проекте за составление и ведение технического задания. ТЗ может в процессе изменятся. И правильным будет вносить в него, по мере необходимости, исправления. Зачем? Затем, что в конце проекта, в процессе приёмо-сдаточных испытаний системы, ее проверяют на соответствие ТЗ, а не на соответствие сиюминутным замечаниям, скажем главного бухгалтера — «А чего оно делает это так?». Назначение ответственного не означает, что исключительно он будет писать это ТЗ, этот специалист будет отвечать за результат — подготовленное по требованиям ГОСТ (или ваших внутренних регламентных документов) техническое задание. А вы, как руководитель проекта будете этот результат проверять.
2. Выяснить, привлекать для подготовки Исполнителя, или вы обойдетесь собственными силами или привлечёте внешних консультантов? В любом случае, подготовка ТЗ потребует определенных расходов.
3. Определить, кто из персонала будет привлечен к подготовке ТЗ, и проконтролировать, чтобы это были знающие тему специалисты и что у них будет достаточно времени для работы в проекте.
4. Определить сроки подготовки ТЗ и график совещаний, в которых в повестку дня будет включен вопрос о ТЗ на ИС. Замечание. Здесь, много уже будет зависеть от конкретной методики ведения проекта.
5. Проконтролировать проект ТЗ (и конечный вариант) по следующим пунктам:
   
   1. Формальные критерии (более полно, в виде проверочного листа вы найдете их ниже).
      
      1. Наличие всех требуемых регламентными документами разделов. Например, по ГОСТ 34.602-89 предполагаются следующие разделы ТЗ:
         
         1. общие сведения;
         2. назначение и цели создания (развития) системы;
         3. характеристика объектов автоматизации;
         4. требования к системе;
         5. состав и содержание работ по созданию системы;
         6. порядок контроля и приемки системы;
         7. требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
         8. требования к документированию;
         9. источники разработки.
         
         Замечание. Всегда следует помнить, что регламентные документы не догма, а инструмент, который, при наличии оснований можно (и нужно) изменять.
      2. Наличие всех подписей согласования, как со стороны Заказчика, так и со стороны Исполнителя.
      3. Наличие листа регистрации изменений с указанием даты и фамилии автора изменений.
   2. Содержательные критерии.
      
      1. Согласованность раздела «Назначение и цели создания системы» с целями и задачами проекта в целом.
      2. В разделе «характеристика объектов автоматизации» должны быть перечислены, как минимум:
         
         1. потребители — подразделения, конкретные рабочие места (не поименно, конечно) данной системы;
         2. затрагиваемые бизнес-процессы.
      3. В разделе «Требования к системе» обязательно должны присутствовать подразделы:
         
         1. функциональные требования. Не обязательно, что они будут здесь детально описаны. Часто выяснение деталей автоматизируемого процесса это часть проекта,
         2. требования к производительности (со ссылкой на способ измерения). Показатели производительности не обязательно должны быть техническими, но обязательно должны быть измеряемыми. Например, скорость реакции интерфейса в секундах — от момента подачи команды, до отображения результата или значка ожидания завершения действия. Финансовому директору, конечно же, нет необходимости разбираться во всех технических деталях. Для него важно чтобы такие критерии присутствовали и затем «перекочевали» в план приёмо-сдаточных испытаний.
         3. требования к надежности (с приведением конкретных показателей надежности). Лучше, если показатели надежности будут выражены в понятных для бизнеса терминах (но при этом опять же, быть измеряемыми). Например, время простоя всей системы при сбое или время исправления ошибки в коде.
         4. требования к эргономичности. Чем больше деталей пользовательского интерфейса и способов взаимодействия с системой будет описано в этом разделе, тем меньше времени проект потратит в дальнейшем на «а передвиньте вот эту пимпочку...», с риском не закончиться никогда.
         5. требования к защите информации и несанкционированного доступа. Часто этим разделом пренебрегают и в дальнейшем либо выясняется, что важные данные «унесли» или исказили, или что, не менее неприятно, из-за проблем с разграничением доступа систему просто невозможно эксплуатировать.
      4. Обязательно должен присутствовать раздел «Порядок контроля и приемки системы». В нем должно быть описано как минимум кто, когда и как подготовит описание приёмо-сдаточных испытаний и что в нем должно быть отражено. В частности обязательно должны присутствовать проверки заданных ТЗ, измеряемых характеристик информационной системы.
      5. Обязательно должен присутствовать раздел «Требования к документированию» — какие документы и когда будут подготовлены и переданы Заказчику.
      6. Еще один раздел, который обычно упускают из вида — «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие». Название длинное, но смысл очень простой — при внедрении системы на сотрудников падет повышенная нагрузка — нужно понимать на кого и в каком объеме. Кроме того в этом разделе необходимо отразить требования по обучению, переподготовке персонала.
6. В процессе работы над проектом необходимо следить за изменениями (имеется в виду процесс управления изменениями в проекте) и те изменения, которые влияют на какие-либо параметры конечной системы, должны быть соответствующим образом задокументированы, и внесены в соответствующую редакцию технического задания.

 

Сценарий 2

Сценарий 2. Финансовый директор — Заказчик (представитель Заказчика). Как Заказчика вас в этом случае будет интересовать в первую очередь результат внедрения информационной системы, выраженный в ответах на следующие вопросы:
 

• Что я получу в конце?
• Сколько это будет стоить?
• Как долго?

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

• Какие функции будет выполнять система?
• Сколько сотрудников будут работать в ней (с детализацией по подразделениям, должностям и квалификации, правам доступа)?

Здесь мы касаемся отдельной большой темы — экономики ИТ проектов. Финансисты склонны считать ROI (Return of investments — возврат инвестиций) для любых затрат, производимых на предприятии. Необходимо предостеречь от поспешных выводов об экономической эффективности или неэффективности проекта. Расчет эффективности целиком и полностью зависит от модели, т. е. от параметров принятых в расчёт. Например, если при расчете ROI для проекта внедрения ERP системы вы примите во внимание только количество «высвободившегося» времени сотрудников (или рабочих мест), а ваши конкуренты уже внедрили ERP, вы рискуете очень скоро оказаться не у дел. Этим примером мы хотели показать, что техническое задание это только одна сторона медали, другой является подготовка и обсчет адекватной модели расчёта ROI проекта внедрения информационной системы.
Расходы на проект зависит от ключевых факторов:
 

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

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

Чек-лист или формальная проверка ТЗ

Если финансовому директору все же пришлось иметь дело с проверкой или написанием
технического задания, то «идеальное ТЗ» должно, согласно ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению», группа ЕСПД («Единая система программной документации») содержать:

1. Разделы:
   
   1. Требования к программе или программному изделию:
      
      1. требования к функциональным характеристикам;
      2. требования к надежности;
      3. условия эксплуатации;
      4. требования к составу и параметрам технических средств;
      5. требования к информационной и программной совместимости;
      6. требования к маркировке и упаковке;
      7. требования к транспортированию и хранению;
      8. специальные требования.
   2. Требования к программной документации.
   3. Технико-экономические показатели.
   4. Стадии и этапы разработки.
   5. Порядок контроля и приемки.
2. Все требования имеют идентификаторы, на которые можно ссылаться.
3. Требования измеряемы и проверяемы. Т.е. можно построить однозначный тест, который даст чёткий ответ — выполнено требование или нет.
4. Требования имеют обоснования, откуда они взялись. Например, имеют ссылки на регламентные документы компании.
5. Требования приоритезированы. Чтобы при урезании бюджета, сроков и других ресурсов было понимание, чем можно пожертвовать.
6. Требования не содержат готовых технических, организационных и других решений.
7. Требования непротиворечивы.
   Замечение. К сожалению, каким бы «продвинутым» не был финансовый директор, представляется маловероятным, что он способен сочетать в себе знания необходимые для проверки или составления
   технического задания, и еще менее вероятно, что он имеет для этого достаточно времени.
8. Требования реализуемы.
9. Требования сформулированы в той форме, которая удобна потребителю требований. Например, оформлены в соответствии с положениями о проектном управлении компании.

Однако в реальной жизни «идеальное ТЗ» это скорее некая цель, к которой следует стремиться, чем что-то осязаемое, потому что очень тяжело и дорого сформулировать требования и потом доказать их полноту.
Хорошим ТЗ является то, в котором записаны 95% процентов всех требований, которые в
принципе нужны для создания правильного результата. Повышение полноты ещё на 5%, грубо говоря, стоит в 10 раз дороже, чем первые 95% требований.
 

Заключение

На практике редко встречается ситуация, когда Заказчик самостоятельно подготовил (или способен подготовить) техническое задание на ИС. Но это не повод отказаться от него. Если образно сравнивать проект по внедрению ИС со стрельбой, то качество технического задания определяет угол между идеальным направлением стрельбы и реальной траекторией снаряда.
Замечание. Как определить качество мы описали в первом сценарии — как минимум, наличие соответствующих разделов и одобрение их всеми сторонами, постоянный контроль и внесение изменений в ТЗ в течение проекта.
Чтобы повысить качество этой «стрельбы» в современной компании должна быть разработана определенная нормативная база, касающаяся проектов. Или хотя бы были разработаны шаблоны проектных документов и частности технического задания. В качестве примера приведем ссылку на шаблон ТЗ http://www.slideshare.net/nzhelnov/3460289-41757162 и пример «ТЗ на разработку АС «Контроля доступа», которые обладают большинством описанных выше признаков «идеального ТЗ».
Нам разумным кажется подход, заключающийся в разбиение проекта как минимум на два этапа:
 

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

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