ГОСТ 24 - Технико-экономическое обоснование (ТЭО)

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

Назначением ТЭО является - дать возможность заказчику обосновать выделение денег у "бюджетодавателя" на ваш проект. Другими словами - ТЭО это бюджетная заявка с обоснованием. Из этого следуют следующие важные для понимания вещи:

1. ТЭО инструмент продажи
2. ТЭО не противоречит и не участвует в процессах PMBook
3. ТЭО задает границы бюджета и состава работ
4. ТЭО пишется заказчиком, но пишите его вы - исполнители
   

ТЭО бывают разные. ГОСТ 24 на ТЭО разбирается ниже, но в целом я встречал две разновидности ТЭО - полноценное ТЭО и ТЭО без обоснования - технико-комерческое предложение без защиты и обоснования необходимости

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

Общая структура ТЭО представлена в ГОСТ24.202-80 и на картинке ниже.

Структура полезная и годная. В целом по этой структуре можно писать любые пресейловые презентации, ТКП, ТЭО, Заявки на финансирование и тп...

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

ничего особенного и у каждого свое. Останавливатся не имеет смысла.

2. Характеристика объекта и сущ системы управления (или автоматизации)

Все как в обычном ТЗ и Пояснительной записке, за одним исключением.

В этом разделе нужно описать ПРОБЛЕМЫ или РИСКИ с которыми сталкивается или может столкнутся заказчик если срочно не потратит эн миллионов на нашу систему.

Этому надо уделить особенное внимание, потому что далее это будет главный текст - зачем надо тратить деньги. И как мы будем обосновывать эффект от внедрения АС.

По структуре можно расскрыть 2-а показателя:

1. Перечень недостатков - это надо расскрывать всегда
2. Перечень экономич потерь - это надо раскрывать только если мы сможете расчитать потери и потом рассчитать экономический эффект от внедрения системы снижающий потери

Что может быть недостатком:

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

3. Цели, критерии и ограничения создания

Здесь все очень просто. По целям и критериям пишем устранение недостатков согласно разделу 2.

По границам - пишем будущие границы проекта. Типа - используем существующие каналы связи, используем только Оракл, делаем систему на 2000 человек и тп.....

4. Ожидаемые технико-экономические результаты

Самый мутный и неприятный раздел. Посути, здесь надо описать ROI, TCO и другое. Я стараюсь всегда ограничится только первыми двумя подразделами.

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

Во втором по сути дается оценка бюджета и плана работ. Здесь уверен все знают что писать -)

Третий писать сложно если численных показателей нет. 

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

Для АПК (аппаратных комплексов) проще,  можно использовать подходы от противного. 1) Например сколько будет стоить эксплуатация старого массива, против установки нового; 2) Сколькобы пришлось купить серверов, если вы не сделаете их виртуализацию. 3) Сколько это стоит у конкурентов

С этим вендоры здорово помогают.

5. Выводы и предложения

С выводами просто - кратко повторяем что реализовав проект мы достигнем целей в устраненеии недостатков

С предложениями еще проще - пишем собственно что мы предлагаем. Сюда можно воткнуть обычное ТКП.

Особенности

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