Тема доклада «1С:СППР, как инструмент по внедрению, разработке и сопровождению информационных систем»
1С СППР = Система Проектирования Прикладных Решений
По рекомендации 1С внедрение и сопровождения систем ERP-класса и иных аналогичных «тяжёлых» систем должно выполняться на СППР, в качестве сопровождающего инструмента.
Выводы по итогам чтения доклада:
В чём содержание определения «СППР многими используется неправильно»?
Во-первых, абсолютное большинство использующих СППР взваливают её на разработчиков.
В таких случаях разработчики отвечают за описание функциональности учётных систем в СППР и за составление задач на разработку.
Вот это и есть неправильно.
С такими задачами справится и JIRA и ей подобные бесплатные продукты.
Работа разработчика в СППР не предусмотрена. СППР должна выдавать разработчику задачи на разработку.
Разработчик от СППР, а значит от совсем других участников проекта, должен получать готовые, детально описанные ТЗ.
Во-вторых, даже работа только системного архитектора в СППР недостаточна.
СППР будет эффективна только тогда, когда в ней будет сделано описание бизнес-процессов организации и, отдельно, описание функциональности программного продукта (разрабатываемого или внедряемого).
А архитектор должен связать каждый бизнес-процесс с функцией системы.
Если чего-то не хватает, то либо делается вывод, что система не подходит под процессы клиента, либо функциональность системы дорабатывается (проектируется в СППР!).
Именно об этом 4-й слайд презентации, который показывает, как отличалось бы описание бизнес-процессов по работе на проекте внедрения самой СППР от функциональности СППР заложенной в конфигурацию.
Вывод — любой проект по внедрению СППР обречён на провал, если он вешается на разработчиков.
СППР должна начинать работу гораздо раньше — при сборе требований и описании бизнес-процессов.
P.S. Модная тема СППР+Vanessa…
Если в СППР делать описание процессов (шагов процессов) по операциям пользователей, то,
фактически, можно получить последовательность операндов языка Геркин для Ванессы.
Т.е. почти готовый сценарий.
Опять вывод, из посткриптума — сценарии должны писать не тестировщики, а те, кто описывает процессы.
От тестировщика (разработчика/программиста) требуется всего лишь перевести шаги процессов в точные команды языка (можно ведь и автоматизировать этот момент, учитывая «человечность» языка геркин).
1С СППР = Система Проектирования Прикладных Решений
По рекомендации 1С внедрение и сопровождения систем ERP-класса и иных аналогичных «тяжёлых» систем должно выполняться на СППР, в качестве сопровождающего инструмента.
Выводы по итогам чтения доклада:
- СППР очень проблемный в использовании продукт
- Причина проблем в том, что СППР используется неправильно
- Интерес к СППР есть, многих волнует как привести в порядок и сделать системным подход к управлению проектами по автоматизации и управлению функциональностью конфигурируемых и сопровождаемых систем.
В чём содержание определения «СППР многими используется неправильно»?
Во-первых, абсолютное большинство использующих СППР взваливают её на разработчиков.
В таких случаях разработчики отвечают за описание функциональности учётных систем в СППР и за составление задач на разработку.
Вот это и есть неправильно.
С такими задачами справится и JIRA и ей подобные бесплатные продукты.
Работа разработчика в СППР не предусмотрена. СППР должна выдавать разработчику задачи на разработку.
Разработчик от СППР, а значит от совсем других участников проекта, должен получать готовые, детально описанные ТЗ.
Во-вторых, даже работа только системного архитектора в СППР недостаточна.
СППР будет эффективна только тогда, когда в ней будет сделано описание бизнес-процессов организации и, отдельно, описание функциональности программного продукта (разрабатываемого или внедряемого).
А архитектор должен связать каждый бизнес-процесс с функцией системы.
Если чего-то не хватает, то либо делается вывод, что система не подходит под процессы клиента, либо функциональность системы дорабатывается (проектируется в СППР!).
Именно об этом 4-й слайд презентации, который показывает, как отличалось бы описание бизнес-процессов по работе на проекте внедрения самой СППР от функциональности СППР заложенной в конфигурацию.
Вывод — любой проект по внедрению СППР обречён на провал, если он вешается на разработчиков.
СППР должна начинать работу гораздо раньше — при сборе требований и описании бизнес-процессов.
P.S. Модная тема СППР+Vanessa…
Если в СППР делать описание процессов (шагов процессов) по операциям пользователей, то,
фактически, можно получить последовательность операндов языка Геркин для Ванессы.
Т.е. почти готовый сценарий.
Опять вывод, из посткриптума — сценарии должны писать не тестировщики, а те, кто описывает процессы.
От тестировщика (разработчика/программиста) требуется всего лишь перевести шаги процессов в точные команды языка (можно ведь и автоматизировать этот момент, учитывая «человечность» языка геркин).
