- PVSM.RU - https://www.pvsm.ru -
Современные финансы, собственно как и деятельность первых менял, это обработка информации. Только если менялы обходились в лучшем случае абаком, финансовому директору приходится иметь дело с неизмеримо большим потоком информации и инструментами для его обработки. Сложность современных
инструментов обработки финансовых данных приводит к тому что, даже если программное обеспечение используется «из коробки», без модификаций, процесс его внедрения в компании может быть достаточно длительным и болезненным. И чтобы этот процесс когда-нибудь закончился и был успешным, финансовый директор оказывается вовлеченным в него самым непосредственным образом. И начинается этот процесс с подготовки технического задания.
Примечание. Мы понимаем что есть еще стандарты на ТЗ от IEEE, ISO и пр. Однако с чего-то же нужно начинать ;-) Мы в Аксиан [1]) придерживаемся свободных взглядов на ТЗ — главное использовать в нем общий с Заказчиком язык.,
 
Первоначально мы предполагали создать только унифицированный чек-лист на тему «Порядок подготовки технического задания на внедрение информационной системы», однако быстро понял, что сделав документ похожим на задание по ЕГ, мы получим результат столь же полезный для финансового директора, как и результаты ЕГ для оценки знаний. Изменив подход, предлагаем вашему вниманию некий алгоритм работы над техническим заданием, с пояснениями, почему мы выполняем то или иное действие. Мы считаем, что руководитель должен делать все действия осознанно, чтобы понимать их последствия. «ЕГ»-шный «чек-лист» не дает такого результата. Тем не менее, ниже вы найдете формальный чек-лист для проверки полноты технического задания, разработанный на базе ГОСТ 34.602-89 и ГОСТ 19.201-78.
Замечание.Формальный — потому что маловероятно, что финансовый директор обладает всей полнотой технических знаний и располагает временем для проверки содержательной части ТЗ.
Несмотря на сложившиеся стереотипы и мифы об информационных технологиях, подготовка технического задания (ТЗ) на информационную систему мало чем отличается от подготовки любого другого ТЗ на любое другое изделие (объект человеческой деятельности). Стоит отметить, что все объекты человеческой деятельности делятся на продукты для конечного потребления и инструменты. Информационные системы (ИС) относятся ко второй категории — это инструмент (в большинстве случаев, если ваш бизнес не выпуск компьютерных игр и т.п.). Это накладывает определенный отпечаток — вы «изготавливаете» инструмент:
С информационными системами на этом моменте понимания происходит путаница: ИС, как правило, создаются для внесения инноваций, модернизации, изменения существующего положения вещей, но при этом участники проекта по внедрению ИС пытаются ее «встраивать» в существующие алгоритмы. Происходит разрыв декларируемых и фактических целей и Заказчик получает не то, что ожидал. Чтобы желаемое не расходилось с действительным важно максимально полно описать «желаемое» в техническом задании.
Присутствие «магических» терминов — «информационная система», «виртуальный» и т. п. не переводит задачу в область эфемерных, высоких материй. Всё также происходит в материальном мире — выполняется и контролируется людьми.
Прежде всего, необходимо определиться с двумя основными вводными фактами:
 
Если мы с вами согласны с этими основными положениями, то попробуем на их основе составить планы работ для подготовки технического задания на внедрение информационной системы. Почему множественное число? Потому что финансовый директор может выступать как минимум в двух ролях при решении такой задачи: он может быть либо руководителем проекта по внедрению информационной системы, либо он может быть представителем Заказчика (заказчиком) такого проекта. Соответственно и его участие в подготовке ТЗ будет разным.
Замечение. Есть еще третья роль — контролёра, когда внедрение ИС непосредственно не касается финансовой или учетной службы, скажем это проект по модернизации кабельной системы службой ИТ. Но мы не будем останавливаться на этой роли, так как она во многом определяется установленными регламентами и внутренней бизнес-культурой компании.
 
Сценарий 1. Финансовый директор — руководитель проекта по внедрению информационной системы. Опустим всё связанное с управлением проектом как таковым, этот вопрос находится в ведении дисциплины проектного управления, наша же задача существенно уже — нас интересует только техническое задание.
 
Замечание. Всегда следует помнить, что регламентные документы не догма, а инструмент, который, при наличии оснований можно (и нужно) изменять.
 
Сценарий 2. Финансовый директор — Заказчик (представитель Заказчика). Как Заказчика вас в этом случае будет интересовать в первую очередь результат внедрения информационной системы, выраженный в ответах на следующие вопросы:
 
В техническом задании содержится ответ только на первый вопрос. Но он поможет в оценке целесообразности и стоимости проекта. Как Заказчика вас интересуют следующие аспекты ответа:
 
Здесь мы касаемся отдельной большой темы — экономики ИТ проектов. Финансисты склонны считать ROI (Return of investments — возврат инвестиций) для любых затрат, производимых на предприятии. Необходимо предостеречь от поспешных выводов об экономической эффективности или неэффективности проекта. Расчет эффективности целиком и полностью зависит от модели, т. е. от параметров принятых в расчёт. Например, если при расчете ROI для проекта внедрения ERP системы вы примите во внимание только количество «высвободившегося» времени сотрудников (или рабочих мест), а ваши конкуренты уже внедрили ERP, вы рискуете очень скоро оказаться не у дел. Этим примером мы хотели показать, что техническое задание это только одна сторона медали, другой является подготовка и обсчет адекватной модели расчёта ROI проекта внедрения информационной системы.
Расходы на проект зависит от ключевых факторов:
 
Замечание. В некоторых компаниях принято в расчет расходов на проект включать стоимость эксплуатации системы в течение года. После чего расходы на ИС переходят из категории CAPEX в OPEX.
При оценке рисков, Заказчику (в нашем случае — финансовому директору) следует
составить таблицу рисков (внешних и внутренних) с оценкой их в денежном и натуральном (временном) исчислении.
Продолжительность проекта в значительной степени зависит от возможностей Исполнителя, но ключевым моментом является способность Заказчика сформулировать четко свои потребности.
И, конечно же, не стоит забывать, что быстро и качественно — это всегда дорого.
 
Если финансовому директору все же пришлось иметь дело с проверкой или написанием
технического задания, то «идеальное ТЗ» должно, согласно ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению», группа ЕСПД («Единая система программной документации») содержать:
Однако в реальной жизни «идеальное ТЗ» это скорее некая цель, к которой следует стремиться, чем что-то осязаемое, потому что очень тяжело и дорого сформулировать требования и потом доказать их полноту.
Хорошим ТЗ является то, в котором записаны 95% процентов всех требований, которые в
принципе нужны для создания правильного результата. Повышение полноты ещё на 5%, грубо говоря, стоит в 10 раз дороже, чем первые 95% требований.
 
На практике редко встречается ситуация, когда Заказчик самостоятельно подготовил (или способен подготовить) техническое задание на ИС. Но это не повод отказаться от него. Если образно сравнивать проект по внедрению ИС со стрельбой, то качество технического задания определяет угол между идеальным направлением стрельбы и реальной траекторией снаряда.
Замечание. Как определить качество мы описали в первом сценарии — как минимум, наличие соответствующих разделов и одобрение их всеми сторонами, постоянный контроль и внесение изменений в ТЗ в течение проекта.
Чтобы повысить качество этой «стрельбы» в современной компании должна быть разработана определенная нормативная база, касающаяся проектов. Или хотя бы были разработаны шаблоны проектных документов и частности технического задания. В качестве примера приведем ссылку на шаблон ТЗ http://www.slideshare.net/nzhelnov/3460289-41757162 [2] и пример «ТЗ на разработку АС «Контроля доступа» [3], которые обладают большинством описанных выше признаков «идеального ТЗ».
Нам разумным кажется подход, заключающийся в разбиение проекта как минимум на два этапа:
 
Используя такой подход, существенно снижаются риски недостижения поставленных целей, перерасхода средств и времени. Более того, даже если после первого этапы принимается решение о нецелесообразности внедрение информационной системы, скорее всего вы узнаете о своем бизнесе много нового.
Автор: AxianLTD
Источник [4]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/upravlenie-riskami/92995
Ссылки в тексте:
[1] Мы в Аксиан: http://axian.ru/
[2] http://www.slideshare.net/nzhelnov/3460289-41757162: http://www.slideshare.net/nzhelnova/3460289-41757162
[3] «ТЗ на разработку АС «Контроля доступа»: http://www.slideshare.net/asimkin/tr-25033271
[4] Источник: http://megamozg.ru/post/16930/
Нажмите здесь для печати.