Что включает в себя предпроектные исследования

Тема 3 Предпроектное исследование

Предпроектное исследование осуществляется с целью параметризации проекта. Это этап сбора необходимых данных и их анализа. Предпроектные исследования позволяют выбрать оптимальный вариант реализации проекта, что позволяет рассчитать необходимые ресурсы, сроки проектирования и повысить эффективность производства. Отдельным этапом работы является изучение функциональности продукта с целью выявления достоинств и недостатков эксплуатации изделия. В ходе предпроектных исследований необходимо продумать несколько основных моментов: для какого сегмента рынка будет выполняться производство, насколько удобно будет использовать данный продукт, что ему необходимо, а что нужно оставить без изменений. Учитываются факты, которые дают понимание того, чем лучше продукт конкурента, и те ошибки, которых нужно избежать в воплощении новой версии продукта. На основе полученных данных формируется техническое задание, строится дизайн-концепция (фор-проект).

· Анализируется полное и формализованное описание существующей проблемы заказчика.

· Проводится анализ состоятельности бизнес-идеи в контексте реальной ситуации на рынке и возможностей организации — заявителя проекта. Четкая постановка целей и задач проекта.

· Проводится экспресс-диагностика ресурсов и потенциала проектной организации, определение стратегических перспектив по совокупности внешних и внутренних факторов компании.

· Определяется социально-культурная потребность целевой аудитории, т.е. предпочтения потребителей.

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

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

Итак, предпроектные исследования перед подготовкой масштабного дизайн-проекта должны включать в себя:

Дата добавления: 2016-01-20 ; просмотров: 5806 ; ЗАКАЗАТЬ НАПИСАНИЕ РАБОТЫ

Источник

Что включает в себя предпроектные исследования

6.3. ПРЕДПРОЕКТНОЕ ИССЛЕДОВАНИЕ и
ТЕХНИЧЕСКОЕ ЗАДАНИЕ

Предпроектное исследование осуществляется с целью параметризации проекта создания АИПС. Сначала выявляются все материальные, финансовые людские и временные ресурсы для выполнения необходимых проектных работ. Это этап сбора необходимых данных и их анализа.

На основе полученных данных формируется Техническое задание (ТЗ) – третий этап проектирования (при необходимости – технико-экономическое обоснование проекта – ТЭО), и собственно проект (четвёртый этап проектирования).

При этом следует отличать работы, связанные с автоматизацией физического труда от работ по автоматизации умственного труда.

Объектами автоматизации могут быть как отдельно взятые, автономные операции или процессы, так и интегральные (интегрированные) системы, требующие обеспечения автоматизации целого комплекса процессов. На основе полученных в процессе проектирования данных в дальнейшем будет приобретаться необходимое оборудование и программное обеспечение, осуществляться монтаж и наладка (при необходимости) оборудования, инициализация (инсталляция, установка) необходимых программ, обучение персонала и опытная эксплуатация создаваемых фрагментов (элементов и подсистем) АИС.

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

Этап анализа предполагает подробное исследование бизнес-процессов и информации, необходимой для их выполнения: сущностей, их атрибутов и связей (отношений). На этом этапе создаётся информационная модель ИС, а на следующем за ним этапе проектирования – модель данных.

Вся собранная информация формализуется и уточняется по результатам её анализа.

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

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

По полученным результатам следует выявить необходимые средства разработки АИС, выбор которых уточняется на этапе анализа. Если предполагаемое средство разработки не позволяет выполнять хотя бы часть работ в заранее заданный срок, то принимают решение об изменении срока (как правило, его увеличении) или о смене средства разработки. Осуществляя выбор средств разработки, следует учитывать наличие персонала, владеющего ими.

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

Необходимо оценивать степень удовлетворения каждой из потребностей Заказчика, связанных с внедрением ИС. При этом не следует забывать, что отсутствие необходимых исходных данных затрудняет проектирование системы.

В рамках предпроектного исследования может осуществляться концептуальное проектирование (conceptual design) – разработка аванпроекта (пилотного проекта) или программы создания системы.

Он должен осуществляться в течение непродолжительного времени иначе Заказчик может потерять интерес к проекту. Важной функцией пилотного проекта является принятие решения относительно приобретения или отказа от использования ИС.

Возможным следующие варианты решения:

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

Техническое задание (ТЗ) – третья стадия проектирования АИС. Оно формируется по результатам проведённого предпроектного исследования и включает разработку и утверждение Технического задания на создание АИС.

Напомним, что разработчики к нему могут и не приступить, если в результате предпрпоектного исследования было выявлено, что Заказчику следует отказаться от использования АИС.

В зависимости от условий создания системы возможны различные совмещения функций заказчика, разработчика, поставщика и других организаций, участвующих в работах по созданию АИС.

В соответствии с ГОСТ 34.601-90 после согласования с заказчиком, выполняется разработка, оформление, согласование и утверждение технического задания (ТЗ) на АИС. Данный стандарт также определяет состав участников проектирования и реализации проектных решений при составлении и (или) согласовании ТЗ.

Легко заметить, что многие его компоненты не только базируются на результатах проведённого предпроектного исследования, но и входят в состав ТЗ.

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

В состав ТЗ на АИС включают приложения, содержащие:
1. Расчёт ожидаемой эффективности системы;
2. Оценку научно-технического уровня системы;
3. Использованные при разработке ТЗ методические и наиболее важные информационные материалы из состава документов указанных в разделе «Источники разработки».

Дополнительные рекомендации по составу и содержанию ТЗ на автоматизированные системы различного назначения и приложений к ним содержатся также в РД 50-640-87 и ГОСТ 24.602-86.

Источник

Предпроектный анализ

Сергей Нужненко darkboatman, ведущий системный аналитик SuperJob, делится опытом запуска IT-проектов с точки зрения аналитика.

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

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

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

Мы знаем, что, во-первых, хорошая постановка задачи — это половина решения, а, во-вторых, не столь важно, насколько продуктивно ты что-то делаешь, если при этом делаешь не то, что нужно. Системной предпроектной работе уделяется удручающе мало внимания. Подавляющее число обсуждений, книг и статей посвящено тому, что делать внутри проекта, или поиску продукта во взаимодействии с рынком. В серой зоне оказывается переход от понимания, что надо продавать, к самой работе.

Задачи предпроекта

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

Предпроект (хоть он и не всегда так называется) может выполняться в разных условиях: на систему в целом, на подсистемы или на каждую фичу продукта.

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

Однако перед тем, как мы начнем фиксировать цели, пресловутые 4 параметра проектного треугольника — формулировать обязанности участников проекта, назначать внешние статус-митинги с участием спонсора и расчехлять другие общеупотребимые инструменты проектного управления — необходимо полностью выполнить задачи предпроекта:

1) Понять сроки и стоимость

2) Допродать систему:

4) Определиться с ресурсами: видами, этапами, сроками, объемами работ и источниками ресурсов

Без этого ничего (хорошего) не выйдет.

Трудности

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

Надо быстро определиться со стоимостью системы на фоне высокой неопределенности.

Идет торг за бюджет и сроки — это конфликт, изначально заложенный в любой предпроект.

Заказчик хочет Сhrysler Escalade, денег есть на ГАЗ 69, но нужен ему Renault Logan. Бывает, что при этом поставщик решений хочет продавать яхты и самолеты, но реально может сделать только надувную лодку, а сейчас пойдет искать, у кого купить Logan.

Проект еще не «продан» и идет борьба за его запуск.

Обзор проблем и решений

Мы расположили частые проблемы предпроекта по мере роста зрелости заказчика и других участников ИТ-проекта:

1) «Письмо Дяди Фёдора»

2) Не учтены полный ЖЦ и структура как системы, так и финансового актива

3) Не учтены задачи предпроектной фазы

Обзор предлагаемых решений, о которых мы более детально поговорим в следующих разделах:

Кроме этого необходимо помнить о базовых принципах, которые мстят за невнимание к себе. Среди них:

Источник

Зачем мобильному приложению нужно предпроектное исследование

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

Делать всё и сразу — не лучшая идея, так как множество фич в первом же релизе могут не окупиться и затягивают time to market. Поэтому разработка приложения начинается с MVP, который можно в дальнейшем развивать. Но чтобы было что улучшать, нужно построить крепкую основу — фундамент.

Именно поэтому перед стартом разработки любого приложения мы предлагаем клиентам начать с предпроектного исследования. Оно помогает решить сразу несколько задач, важных для коммерческого успеха продукта:

Мы в Surf более 10 лет разрабатываем флагманские мобильные приложения — нативные и на Flutter. Среди наших клиентов — Литрес, Росбанк, KFC, РИВ ГОШ.

💼 Рассказываем об этом в наших кейсах.

📱 Недавно мы запустили канал в Telegram, в котором делимся своим продуктовым видением. Подписывайтесь!

Чтобы планировать долгосрочное развитие, важно не ошибиться в самом начале и правильно выстроить стратегию продукта. Успех продукта и его ключевые метрики: месячная и дневная аудитория, возвращаемость в продукт (Retention Rate), срок жизни пользователя в продукте (CLT — Customer Life Time) — напрямую связаны с бизнес-целями. И как следствие, с тем, насколько продукт будет прибыльным.

Предпроектное исследование мы разделяем на несколько этапов:

Давайте рассмотрим каждый из них.

Что делаем на этом этапе. Внимательно слушаем заказчика и то, что он рассказывает о своём бизнесе и своих клиентах: кто они, как любят совершать покупки, довольны ли приложением, если оно уже есть. Работаем в тандеме: наша команда и команда заказчика. Для того чтобы структурировать ответы:

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

Что делаем на этом этапе. Тут нет отдельной команды заказчика и команды Surf. Мы объединяемся в единую с общей целью — построить успешный продукт, который решает задачи и бизнеса, и потребителей. Для этого мы изучаем пользователя: его текущий опыт, боли, потребности, мотивацию. Продолжаем углубляться в рынок: исследуем существующие решения, конкурентов, их недостатки, достоинства и проблемы.

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

Что делаем на этом этапе. Составляем карту пути пользователя — CJM (customer journey map). Используем универсальный маркетинговый инструмент, который может сослужить хорошую службу при проектировании мобильного приложения. В формате воркшопа:

Мы работаем в формате двухдневного воркшопа — мозгового штурма, в котором участвуют и специалисты Surf, и сотрудники компании-заказчика из разных отделов, так или иначе вовлечённых в продукт.

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

Наши заказчики ценят CJM за прозрачность. Ведь в рамках этой работы мы определяем набор функциональности продукта, после чего выделяем функции, необходимые для MVP, и планируем дальнейшее развитие приложения.

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

Кейс Surf. Этап CJM крайне важен, так как он позволяет определить слабые места приложения. Поэтому мы подробно останавливаемся на негативных юзкейсах. Рассмотрим на примере приложения доставки еды. Когда пользователь заказывает еду, он голоден и не хочет долго ждать. Любая негативная ситуация вызывает у него особенно острую реакцию. Поэтому тут важно определить все возможные негативные сценарии и свести их к минимуму.

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

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

Чаще всего опрашиваем от 15 до 30 респондентов из разных сегментов. Количество определяется для каждого проекта индивидуально, в зависимости от числа сегментов аудитории.

Дополняем процесс методологией Jobs To Be Done — это актуальный продуктовый фреймворк. Он позволяет наблюдать и анализировать потребности людей на разных уровнях: от жизненных целей до небольших рутинных действий.

Для чего это нужно. С помощью глубинного интервью мы определяем и приоритезируем сегменты аудитории будущего продукта. В результате клиент получает подробный документ с выводами и гипотезами. Мы узнаём:

Кейс Surf. В работе над приложением Бетховен на этапе Сustdev с клиентами зоомагазинов мы выяснили, что есть два основных фактора, которые привлекают их в приложение конкретного магазина:

Самое важное на этапе касдева — бережно собрать все найденные инсайты и артефакты. Одним из инсайтов кейса Бетховен стал тот факт, что у пользователей нет привязки к бренду, а есть потребность в быстрой и удобной покупке ходовых товаров для своих питомцев. Это и реализовали в приложении: мы детально проработали весь флоу заказа, сделав покупку лёгкой и быстрой.

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

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

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

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

Дальше проект переходит уже на первые этапы разработки, к ним мы относим прототипирование и UX-тестирование. Кратко остановимся и на них. На основе собранных артефактов мы создаём прототип приложения: проектируем экраны в Figma, собираем кликабельные прототипы в Invision/Figma.

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

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

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

Например, в e-commerce мы больше внимания уделяем флоу заказа, так как конечная цель торгового приложения — это покупка — лёгкая и быстрая. О том, как мы это делаем, можно прочитать в нашем блоге. Фудтех работает с одной из самых «опасных» аудиторий — голодной и нетерпеливой. Поэтому тут важно проработать все возможности, связанные с быстрой доставкой — именно этот фактор является одним из определяющих в фудтех-приложении.

В банковском приложении больше пользовательских сценариев, чем у других направлений: если в e-commerce основная задача приложения — дать возможность быстро совершить покупку, мобильный банк решает намного больше задач: это и оформление новых банковских продуктов, и работа с существующими, и переводы и платежи, и интеграция с внешними системами. Поэтому времени на предпроектное исследование в финтехе потребуется гораздо больше.

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

Усложняется предпроектное исследование и в тех ситуациях, когда проект подразумевает несколько ролей: например, предполагается, что с сервисом будут работать студент и преподаватель, врач и пациент, водитель и пассажир. В этом случае работать нужно уже не только с разными сценариями использования, но и с разными потребностями. В итоге, предпроектное исследование может показать, что для решения задач двух разных ЦА нужны два отдельных приложения.

Однако, в целом, методология проведения CJM и касдева от отрасли к отрасли не сильно меняется. В каждом проекте мы следуем по одному и тому же пути. Может меняться только сложность сценариев и ролей пользователей.

Вне зависимости от сферы бизнеса, предпроектное исследование будет полезно и поможет создать эффективный продукт в нескольких случаях:

За предпроектные исследования в Surf отвечает Product Lab — наше консалтинг-подразделение, которое выпустило в свет уже не один десяток успешных приложений. Они формируют и проверяют гипотезы, помогают настроить работу продуктовых команд, строят roadmap продуктов.

Чтобы узнать больше о технологиях и трендах, подписывайтесь на наш канал в Telegram.

Источник

Предпроектные исследования

Первым этапом инвестиционного проекта создания конкурентоспособного изделия является этап «Предпроектные исследо­вания», структура и виды работ на данном этапе представлены на рис. 2.4.

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

При этом обосновываются область применения будущего изде­лия, техническое задание на него и показатели конкурентоспособ­ности.

Следующим шагом являются маркетинговые исследования, по результатам которых, как показывает практика, может быть уточ­нено техническое задание и сформированы тактико-технические требования [ТТГ] на изделие, обладающее высокими показателя­ми конкурентоспособности [П-К].

Одновременно формируется техническое задание на инвести­ционной проект в целом.

На основании отчета по маркетинговым исследованиям разра­батывается бизнес-план на проект

Структура этапа «Предпроектные исследования»

Этап предпроектных исследований комплексного проекта вклю­чает в себя следующую последовательность работ (см. рис. 2.4).

Одним из основных направлений деятельности на этапе пред­проектных исследований является маркетинг-исследование со­стояния рынка продукции, на который будет направлено изделие, созданное в рамках проекта.

В общем случае содержание работ по изучению рынка включает:

• изучение масштабов потенциально возможной ниши рынка и ее емкости;

• исследование требований потребителей к подобной продук­ции;

• исследование направлений научно-исследовательской и про­изводственной деятельности организаций и фирм, которые дейс­твуют на рынке

• создание имиджа компании;

• организация и ведение конкурентной борьбы;

• комбинирование и координация средств и направлений де­ятельности компании;

Маркетинговая деятельность развивается системно, по следую­щим направлениям, это так называемая концепция «SP»:

1. Product — товарная политика фирмы (товарный маркетинг), ориентированная на рынок ассортиментного ряда товаров.

2. Price — ценовая политика компании (ценовой маркетинг), ориентированная на рынок разработки уровня и поведения цен, ценовых методов стимулирования сбыта.

4. Place — место и время продажи, товародвижение (сбытовой маркетинг, дистрибьюция) — выбор оптимальных каналов сбыта и торговых посредников, организация хранения.

5. People — продавцы и покупатели (маркетинг отношений) — разработка кадровой политики компании (подбор и обучение пер­сонала, ориентированного на клиента и цели фирмы).

Концепция «SP» (комплекс) на практике реализуется в структу­ре функционального маркетинга (табл. 2.1).

Кроме функциональной выделяется отраслевая структура мар­кетинга:

• индустриальный маркетинг (ориентированный на корпора­тивных клиентов);

• потребительский (ориентированный на конечного потреби­теля);

• маркетинг промышленной продукции;

• маркетинг интеллектуального продукта;

В зависимости от характера спроса на товары различают следу­ющие виды маркетинга:

• конверсионный маркетинг, связанный с наличием пассив­ного спроса. Задачи конверсионного маркетинга — зарождение спроса на продукцию;

• стимулирующий маркетинг, связанный с наличием това­ров, на которые нет спроса. Задача стимулирующего маркетинга — учесть причины безразличия и преодолеть их;

• развивающий маркетинг, связанный с формирующимся спросом на изделия. Задача развивающего маркетинга — превра­щение потенциального спроса в фактический;

• ремаркетинг. связанный со снижением спроса в определен­ный период угасания жизненного цикла товаров. Задача ремаркетинга — оживление спроса при помощи новых возможностей мар­кетинга, например, с помощью новых рыночных свойств;

• синхромаркетинг связан с колеблющимся спросом, напри­мер сезонным. Сглаживание или усиление (в зависимости от це­лей) сезонных колебаний спроса — задача синхромаркетинга;

• поддерживающий маркетинг используется, когда уровень и структура спроса на продукцию полностью соответствует уровню и структуре предложения;

• демаркегинг используется, когда спрос на продукцию чрез­мерно превышает предложение и нет возможности увеличить объ­ем производства;

• выявление торговых марок (товарных знаков), используемых фирмами-конкурентами;

• обоснование конкретных требований к созданию новой кон­курентоспособной продукции в рамках проекта;

• технико-экономический анализ и обоснование выбора тех­нических решений (из числа известных объектов промышленной собственности), отвечающих запросам потребителей;

• возможный анализ деятельности хозяйствующих субъектов на выбранном секторе рынка и определение для себя оптимальных направлений развития научно-технической, производственной и коммерческой деятельности;

• выявление технических, конструкторских, программных и других решений, которые могут быть созданы в процессе выполне­ния НИР и ОКР в рамках проекта с целью отнесения их к охранос­пособным объектам интеллектуальной собственности, в том числе промышленной;

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

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

• выявление и отбор объектов лицензий и услуг инжиниринга. Одним из основных моментов исследования рынка является

обоснование целесообразности и форм проведения в стране и за рубежом коммерческих мероприятий по реализации объектов хо­зяйственной деятельности, по закупке лицензий, оборудования, сырья, комплектующих изделий, которые понадобятся при реали­зации «Проекта создания конкурентоспособной продукции».

Все эти материалы должны быть положены в основу разработки бизнес-плана проекта.

Источник