1.1 Демонстрация проводится по пунктам ТФС. По каждому пункту ТФС в графе "Резюме для ЦС" проставляются следующие виды статусов:

1.2 При подготовке демонстрации как для внутренних встреч, так и для согласования с заказчиком, в обязательном порядке формировать раздатку по демонстрируемым БП в виде:

Пример пути к итоговым ТФР по этапу 1.

Раздатку формируют лица, проводившие анализ\моделирование и проводящие демонстрации ТФР в срок до начала внутренней демонстрации.

1.3 В таблице ТФР по графам не предусматривающим заполнение ставить "-".

1.4 При демонстрации ФР акценты расставлять на типовом функционале, а не максимальном копировании учета заказчика.

1.5 Каждый ФР должен иметь итоговое резюме автора ФР, агрегирующее мнения экспертов (при наличии), отраженное в графе 22. Указанное резюме должно быть сформулировано четко и с оптимальной смысловой нагрузкой выдвигаемой оптимизации\предложения (не формальная отписка можно\нельзя) и содержать следующие тезисы в зависимости от предлагаемого решения:

1.6 Демонстрация операций аналитиком проводится отдельно от демонстрации ПФ, проводимой методологами.

1.7 Все рабочие документы, используемые для анализа и формулирования выводов по ФР должны храниться на портале.

2.     Электронные документы, проводки, ПФ. Функционал аналитика.

2.1  На момент проведения демонстрации заказчику в ЦС должны быть отмоделированы все операции, отраженные в ТФС.

2.2  Демонстрации подлежат ФР в следующих вариациях:

Необходимо четко озвучивать пункт ФР перед его демонстрацией, далее проводить демонстрацию, далее озвучить пути решения\оптимизации.

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

2.4  Обращать внимание на проводки в БУ, НУ. При необходимости демонстрировать взаимосвязи с Бюджетирование и МСФО. Бегло демонстрировать типовые ПФ документов, формируемые в документах к показу. Обращать внимание на формирование регистров.

2.5  При наличии демонстрировать ПФ отчетов.

2.6  Акцентировать внимание на журналы документов, наличие фильтров и отборов типового функционала.

3.     ПФ. Функционал методолога.

3.1  Демонстрировать типовые ПФ с озвучиванием ФР. По каждому ФР в обязательном порядке должно присутствовать итоговое резюме автора (см. п.1.5).

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

3.2  Нереализованные в ЦС ПФ предоставлять отдельным реестром заказчику для согласования их актуальности к доработке вместе с раздаточными материалами по ФР. Срок предоставления раздаточных материалов см. п. 1.2.

3.3  ПФ с доработкой только в виде штрих кода предоставлять отдельным реестром заказчику для согласования их актуальности к доработке вместе с раздаточными материалами по ФР. Срок предоставления раздаточных материалов см. п. 1.2.

3.4 При отработке ПФ, перечислять все их виды (шаблоны) доступные в УС Заказчика.

Перед демонстрацией направлять списки всех имеющихся ПФ в УС для подтверждения их актуальности заказчиком. При необходимости на демонстрации актуализировать данные по применимости перечисленных ПФ.

1. Моделировать по принципу максимального соответствия данным заказчика

- префиксы

- наименования номенклатур

- субсчета и т.д.

Исключения: порядковые номера элементов ЦС, автонумерация и т.п.

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

Тайминг 15 минут по зафиксированным в ТФР ФР с демонстрацией в ЦС:

- Озвучить требование заказчика,

- Демонстрация операций в ЦС,

- Озвучить ФР и пути решения с учетом рекомендаций разработчиков, методологов.

Например, номенклатура: Mold 315/70 R22,5 Cordiant Professional FR-1_БАА.

1. Состав и структура проекта

Проект = Кордиант Автоматизация

Типы задач проекта: задача, подзадача, эпик.

Эпики (групповые задачи) = этапы проекта.

Задачи (таски) -укрупненные задачи= отрабатываемым бизнес- процессам. Входят в состав эпиков.

Подзадачи (субтаски)- конкретные мелкие задачи в рамках одного вопроса либо перечня однородных вопросов в рамках одного бизнес- процесса. Входят в состав таски.

Комментарии (в рамках тасков и субтасков)- использовать для оперативного решения вопросов по поставленным задачам, адресованных конкретному пользователю.

Обязательные поля (выделено красным):

- Наименование задачи

- Описание задачи (если пунктов больше одного, обязательно формируем пронумерованным списком)

- Дата начала

- Срок исполнения

- Автор

- Исполнитель

- Статус

-- Выполнить - автоматически устанавливается при создании задачи,

-- В работе - ручной выбор исполнителем при принятии в работу,

-- На паузе - ручной выбор исполнителем при приостановке выполнения задачи по объективным причинам. Обязательно описать в комментарии причины.

-- Проверка - ручной выбор исполнителем при отправке на проверку постановщику задачи. Обязательно описать в комментарии по готовности задачи.

-- Отмена - ручной выбор исполнителем в случае отмены поставленной задачи. Задачи не удаляем, а отменяем. Обязательно описать в комментарии о причине отмены.

ВАЖНО: после выполнения задачи поле "Исполнитель", "Соисполнители" остается неизменным, меняется только статус выполнения эпика\таска\субтаска.

Прочие поля (выделено зеленым) - зависит от условий задачи:

- Приоритет

- Соисполнители

- Наблюдатели

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

Пользователи без прав администратора (т.е все кроме Благина, Барышниковой, Керн, Петрова) в задачах Jira изменять чужие комментарии не могут, поэтому в ответ должны создавать свои комментарии, содержащие следующие параметры: номер пункта, «Исполнено» либо комментарии о сложности исполнения, дата.