Презентация по докладу «1С СППР, как инструмент по внедрению, разработке и сопровождению информационных систем» на Инфостарт 2019.
Выводы по итогам чтения доклада:
1) СППР очень проблемный в использовании продукт
2) Причина проблем в том, что СППР используется неправильно
3) Интерес к СППР есть, многих волнует как привести в порядок и сделать системным подход к управлению проектами
по автоматизации и управлению функциональностью конфигурируемых и сопровождаемых систем.

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

PS Модная тема СППР+Vanessa...
Если в СППР делать описание процессов (шагов процессов) по операциям пользователей, то,
фактически, можно получить последовательность операндов языка Геркин для Ванессы.
Т.е. почти готовый сценарий.
Опять вывод, из посткриптума - сценарии должны писать не тестировщики, а те, кто описывает процессы.
От тестировщика (разработчика/программиста) требуется всего лишь перевести шаги процессов в точные команды языка (можно ведь и автоматизировать этот момент, учитывая "человечность" языка геркин).