Технико-экономическое обоснование представляет из себя интересный и потенциально очень геморойный документ. Не зря его никто не любит.
Назначением ТЭО является - дать возможность заказчику обосновать выделение денег у "бюджетодавателя" на ваш проект. Другими словами - ТЭО это бюджетная заявка с обоснованием. Из этого следуют следующие важные для понимания вещи:
Назначением ТЭО является - дать возможность заказчику обосновать выделение денег у "бюджетодавателя" на ваш проект. Другими словами - ТЭО это бюджетная заявка с обоснованием. Из этого следуют следующие важные для понимания вещи:
- ТЭО инструмент продажи
- ТЭО не противоречит и не участвует в процессах PMBook
- ТЭО задает границы бюджета и состава работ
- ТЭО пишется заказчиком, но пишите его вы - исполнители
ТЭО бывают разные. ГОСТ 24 на ТЭО разбирается ниже, но в целом я встречал две разновидности ТЭО - полноценное ТЭО и ТЭО без обоснования - технико-комерческое предложение без защиты и обоснования необходимости
Писать ТЭО не любят именно из-за тупого требования обязательной экономической выгоды. Которая не всегда очевидна, а часто ее и нет. Поэтому главная задача при написании ТЭО обосновать через технические выгоды -)
Общая структура ТЭО представлена в ГОСТ24.202-80 и на картинке ниже.
Структура полезная и годная. В целом по этой структуре можно писать любые пресейловые презентации, ТКП, ТЭО, Заявки на финансирование и тп...
1. Общие положения
ничего особенного и у каждого свое. Останавливатся не имеет смысла.
2. Характеристика объекта и сущ системы управления (или автоматизации)
Все как в обычном ТЗ и Пояснительной записке, за одним исключением.
В этом разделе нужно описать ПРОБЛЕМЫ или РИСКИ с которыми сталкивается или может столкнутся заказчик если срочно не потратит эн миллионов на нашу систему.
Этому надо уделить особенное внимание, потому что далее это будет главный текст - зачем надо тратить деньги. И как мы будем обосновывать эффект от внедрения АС.
По структуре можно расскрыть 2-а показателя:
- Перечень недостатков - это надо расскрывать всегда
- Перечень экономич потерь - это надо раскрывать только если мы сможете расчитать потери и потом рассчитать экономический эффект от внедрения системы снижающий потери
Что может быть недостатком:
- Несоответствие нормативам гос и ведомственным (например закону о персональных данных) - наилучшей недостаток, имхо
- Новые направления бизнеса - предполагается что все обоснование по деньгам уже сделано
- Невозможность соответствовать заданым временным нормативам по обработке документов (все системы бизнес деятельности)
- Недостаточная производительность, надежность, непрерывность
- Недостаточность человеческих ресурсов - но надо суметь далее доказать что это лечится
3. Цели, критерии и ограничения создания
Здесь все очень просто. По целям и критериям пишем устранение недостатков согласно разделу 2.
По границам - пишем будущие границы проекта. Типа - используем существующие каналы связи, используем только Оракл, делаем систему на 2000 человек и тп.....
4. Ожидаемые технико-экономические результаты
Самый мутный и неприятный раздел. Посути, здесь надо описать ROI, TCO и другое. Я стараюсь всегда ограничится только первыми двумя подразделами.
В первом, перечень источников эфективности, можно привести перечень функций системы и дать связку как эти функции позволяют достигать заявленные цели (см раздел 3) для устранения указанных недостатков (см раздел 2). Чистая вода.
Во втором по сути дается оценка бюджета и плана работ. Здесь уверен все знают что писать -)
Третий писать сложно если численных показателей нет.
Для АС один из подходов который я использую заключается в расчете того сколько человеко часов будет стоить операция без системы, а сколько после внедрения системы
Для АПК (аппаратных комплексов) проще, можно использовать подходы от противного. 1) Например сколько будет стоить эксплуатация старого массива, против установки нового; 2) Сколькобы пришлось купить серверов, если вы не сделаете их виртуализацию. 3) Сколько это стоит у конкурентов
С этим вендоры здорово помогают.
5. Выводы и предложения
С выводами просто - кратко повторяем что реализовав проект мы достигнем целей в устраненеии недостатков
С предложениями еще проще - пишем собственно что мы предлагаем. Сюда можно воткнуть обычное ТКП.
Особенности
Для гос заказчика возможно требование приложить к ТЭО - Сводный сметный расчет, включая спецификцию ПО и техники. А это уже почти полное проектирование
Комментариев нет:
Отправить комментарий