Министерство финансов Российской Федерации
ФЕДЕРАЛЬНАЯ НАЛОГОВАЯ СЛУЖБА

ПРИКАЗ

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

приказываю:

1.1. Приложение N 2 к Приказу "Порядок ведения Перечня технологических процессов ФНС России" изложить в редакции согласно приложению N 1 к настоящему приказу.

1.2. Приложение N 3 к Приказу "Регламент разработки паспортов функций и ведения реестра паспортов функций" изложить в редакции согласно приложению N 2 к настоящему приказу.

2. Структурным подразделениям центрального аппарата ФНС России, Межрегиональной инспекции ФНС России по централизованной обработке данных (А.Ю.Щеверов) обеспечить исполнение настоящего приказа.

3. Управлению модернизации налоговых органов (И.А.Мирошникова) обеспечить методологическое сопровождение ведения реестра паспортов функций.

4. Контроль за исполнением настоящего приказа возложить на заместителя руководителя Федеральной налоговой службы С.Н.Андрющенко.

Руководитель
Федеральной налоговой службы
М.В.Мишустин

Приложение N 1

к приказу ФНС России

Порядок ведения перечня технологических процессов ФНС России

1. Общие положения

1.1. Перечень технологических процессов ФНС России (далее - Перечень) представляет собой систематизированный посредством классификационных группировок свод всех регламентированных последовательностей взаимосвязанных действий, осуществляемых ФНС России, ее территориальными налоговыми органами и подведомственными ФНС России организациями, направленных на достижение заданного результата в сфере обеспечения функционирования, развития и реализации полномочий ФНС России (далее - технологические процессы ФНС России).

1.2. Перечень предназначен для систематизации технологических процессов ФНС России и кодирования информации о них, а также для указания начальников структурных подразделений центрального аппарата ФНС России, ответственных за получение результата по технологическому процессу ФНС России, методологическое и/или организационное сопровождение его выполнения (далее - владелец технологического процесса ФНС России).

1.3. Также в Перечне при необходимости указывается начальник структурного подразделения центрального аппарата ФНС России, ответственный за получение результата по отдельным составным частям технологического процесса (далее - операции) и методологическое сопровождение их выполнения (далее - совладелец технологического процесса ФНС России).

1.4. Целью формирования Перечня является определение всех технологических процессов ФНС России и их владельцев (совладельцев) для обеспечения эффективной взаимосвязи и взаимодействия организационных, технологических, информационных и других ресурсов в рамках комплексного подхода к осуществлению деятельности ФНС России.

1.5. Систематизация технологических процессов ФНС России в Перечне основана на иерархическом методе классификации и последовательном методе кодирования.

1.6. Принципом систематизации является группировка технологических процессов ФНС России, выполняемых в рамках реализации функции/услуги/полномочия. При этом первоначальным является разделение всей совокупности технологических процессов ФНС России на основные технологические процессы ФНС России, а также вспомогательные и управленческие технологические процессы ФНС России.

1.7. Актуальный Перечень доступен для просмотра по ссылке, размещенной на Интранет-портале ФНС России.

1.8. Декомпозиция технологических процессов ФНС России для формирования Перечня осуществляется до уровня, при котором результатом выполнения является ценность в виде оформленного решения (документа) лица, уполномоченного на его принятие (утверждение, подпись) в соответствии с документом (нормативным правовым актом и/или приказами, планами, письмами, разъяснениями, методическими рекомендациями и т.п., а также поручениями руководства ФНС России и других ведомств), регламентирующим выполнение технологического процесса ФНС России.

1.9. Декомпозицией 1-го уровня является классификация технологических процессов ФНС России на:

- технологические процессы ФНС России, выполняемые непосредственно в целях реализации полномочий в сфере налогообложения, государственных функций, государственных услуг, а также информационного взаимодействия в соответствии с заключенными соглашениями, положениями и протоколами (далее - основные технологические процессы ФНС России);

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

2. Кодирование технологических процессов ФНС России

2.1. Код технологического процесса ФНС России (далее - ТП) состоит из 13 цифровых знаков, отделенных точками в соответствии со следующей структурой XXX.XX.XX.XX.XXXX, где:



Подкласс ТП	Группа ТП 1-го уровня	Группа ТП 2-го уровня

Класс ТП группирует технологические процессы ФНС России, выполняемые в рамках нескольких функций/услуг/полномочий. При этом код класса ТП присваивается следующим образом:

- для основных технологических процессов ФНС России код класса ТП присваивается последовательно с увеличением на 1 в рамках 1XX, начиная с "101";

- для вспомогательных и управленческих технологических процессов ФНС России код класса ТП присваивается последовательно с увеличением на 1 в рамках 2XX, начиная с "201".

Подкласс ТП группирует технологические процессы ФНС России, выполняемые в рамках функции/услуги/полномочия. Код подкласса ТП присваивается, начиная с "01", с последовательным увеличением на 1. Нумерация начинается заново для подклассов ТП каждого класса ТП.

Группы ТП 1-ого и 2-ого уровней предназначены для систематизации технологических процессов ФНС России в рамках одной функции/услуги/полномочия, если количество технологических процессов ФНС России значимо и такая систематизация требуется (в целях упорядочения расположения технологических процессов ФНС России в подклассе ТП).

По умолчанию код группы ТП 1-ого уровня равен "00". Код группы ТП 1-ого уровня присваивается, начиная с технологических процессов ФНС России, которые требуется сгруппировать в рамках подкласса ТП, - начиная с 01, с последовательным увеличением на 1. Если до указанных технологических процессов ФНС России в классификации расположены технологические процессы ФНС России, не требующие группировки, то код группы ТП 1-ого уровня равен "00". Для технологических процессов ФНС России, расположенных после технологических процессов ФНС России, объединенных одним кодом группы ТП 1-ого уровня, нумерация кода группы ТП 1-ого уровня продолжается.

По умолчанию код группы ТП 2-ого уровня равен "00". Код группы ТП 2-ого уровня присваивается, начиная с технологических процессов ФНС России, которые требуется сгруппировать в рамках группы ТП 1-ого уровня, - начиная с 01, с последовательным увеличением на 1. Если до указанных технологических процессов ФНС России в классификации расположены технологические процессы ФНС России, не требующие группировки, то код группы ТП 2-ого уровня равен "00". Для технологических процессов ФНС России, расположенных после технологических процессов ФНС России, объединенных одним кодом группы ТП 2-ого уровня, нумерация кода группы ТП 2-ого уровня продолжается.

Нумерация начинается заново для группы ТП каждого подкласса ТП.

В целях систематизации используется код группы ТП 1-ого уровня (код группы ТП 2-ого уровня имеет значение "00"), при необходимости дополнительной группировки применяется код группы ТП 2-ого уровня, кодировка осуществляется аналогично кодировке с помощью кода группы ТП 1-ого уровня.

Номер ТП предназначен для определения положения технологического процесса ФНС России в подклассе ТП (при использовании кода группы ТП - в группе ТП уровня 1, 2 подкласса ТП). Номер ТП присваивается, начиная с "0010", с последовательным увеличением на 10 для обеспечения возможности добавления нового ТП, обеспечив его необходимое расположение в подклассе ТП (с учетом кода группы ТП). Нумерация начинается заново для каждого подкласса класса ТП (при использовании кода группы ТП уровня 1 - для каждой группы ТП уровня 1 подклассов каждого класса ТП, при использовании кода группы ТП уровня 2 - для каждой группы ТП уровня 2 каждой группы ТП уровня 1).

2.2. Технологический процесс ФНС России характеризуется кодом ТП, в котором значения класса ТП, подкласса ТП и номера ТП не нулевые.

Код XXX.XX.XX.XX.0000, где код класса ТП, подкласса ТП и группы ТП уровня 1, 2 - не нулевые значения, характеризует признак систематизации технологических процессов ФНС России в рамках подкласса ТП, определенный кодом группы ТП уровня 1, 2, и не является кодом технологического процесса.

Код XXX.XX.00.00.0000, где код класса и подкласса ТП - не нулевые значения, характеризует признак подкласса ТП и не является кодом технологического процесса ФНС России.

Код XXX.00.00.00.0000, где код класса ТП - не нулевое значение, характеризует признак класса ТП и не является кодом технологического процесса ФНС России.

3. Порядок внесения изменений в Перечень

3.1. Основаниями для внесения изменений в Перечень являются изданные нормативные правовые акты, приказы, планы, письма, разъяснения, методические рекомендации и т.п., а также поручения руководства ФНС России и других ведомств, определяющие необходимость введения нового/исключения действующего технологического процесса ФНС России, изменения его наименования, либо владельца/совладельца технологического процесса ФНС России.

3.2. При возникновении основания для внесения изменений в Перечень структурное подразделение центрального аппарата ФНС России, начальник которого является/являлся владельцем или совладельцем технологического процесса ФНС России, направляет заявку в адрес Управления модернизации налоговых органов по форме согласно приложению к настоящему Порядку.

3.3. Если внесение изменений в Перечень подразумевает изменение (назначение) владельца/совладельца технологического процесса ФНС России, заявка должна быть согласована со структурными подразделениями центрального аппарата ФНС России, начальники которых являются предлагаемыми/действующими владельцами/совладельцами технологического процесса ФНС России.

3.4. При исключении/добавлении технологического процесса ФНС России коды других технологических процессов ФНС России не меняются. Коды технологических процессов ФНС России, ранее исключенных из Перечня, не присваиваются другим технологическим процессам ФНС России.

3.5. Не позднее 5 рабочих дней после получения заявки на внесение изменений в Перечень Управление модернизации налоговых органов проверяет выполнение пунктов 3.1, 3.3 и 3.4, полноту и отсутствие избыточности предлагаемого наименования технологического процесса ФНС России (класса, подкласса, группы), отсутствие пересечений указанной деятельности с другими технологическими процессами ФНС России и вносит изменения в Перечень или направляет мотивированный отказ.

Приложение
к Порядку ведения Перечня
технологических процессов
ФНС России

Заявка на внесение изменений в Перечень технологических процессов ФНС России (Перечень)


	добавлением нового технологического процесса ФНС России
	внесением изменений в технологический процесс ФНС России
	исключением технологического процесса ФНС России

просит внести следующие изменения в Перечень:


	В действующей редакции	Предлагаемые изменения
Наименование технологического процесса ФНС России
Код технологического процесса ФНС России
Владелец технологического процесса ФНС России
Совладелец (совладельцы) технологического процесса ФНС России
Подлежит автоматизации в централизованных компонентах АИС "Налог-3" (с внедрением до 2020 года включительно)

Наличие автоматизации
Основание для внесения изменений


Начальник структурного подразделения центрального аппарата ФНС России - владелец технологического процесса, согласно действующему Перечню
	Подпись/ФИО/
Начальник структурного подразделения центрального аппарата ФНС России, предлагаемый в качестве владельца технологического процесса
	Подпись/ФИО/
Начальник структурного подразделения центрального аппарата ФНС России - совладелец технологического процесса
	Подпись/ФИО/

________________
Указываются сведения о существующем технологическом процессе ФНС России при его исключении или внесении изменений.

Заполняется при введении нового технологического процесса ФНС России или внесении изменений в существующий технологический процесс ФНС России.

Наименование должно выражать действие и не превышать 255 символов.

Указывается "Да" или "Нет".

Указывается, если существует паспорт функции в статусе "Рекомендован".

Указывается программное обеспечение (СЭОД, ПК Регион, АИС ФЦОД, централизованные компоненты АИС "Налог-3", таблицы Excel, иное) или "Отсутствует".

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

В случае предложения по изменению владельца существующего технологического процесса ФНС России, а также введении нового технологического ФНС России.

Если заполнено поле "Совладелец (совладельцы) технологического процесса ФНС России" в столбце "В действующей редакции" или "Предлагаемые изменения".

Приложение N 2

к приказу ФНС России
от "__" __________ 2016 года N ____

Регламент разработки паспортов функций и ведения реестра паспортов функций

1. Общие положения

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

1.2. Паспорт функции содержит структурированный набор графических представлений (диаграмм) одного технологического процесса ФНС России, состав действий (операций), включая действия (операции), одинаковые для выполнения в различных технологических процессах ФНС России (далее - типовые процедуры), их параметры, входные и выходные данные, поставщиков входных данных, потребителей выходных данных, взаимосвязи с другими технологическими процессами ФНС России.

1.3. Разработка паспортов функций выполняется только для технологических процессов ФНС России, которые подлежат дальнейшей автоматизации в централизованных компонентах АИС "Налог-3". При наличии в подлежащем автоматизации в АИС "Налог-3" технологическом процессе ФНС России не автоматизируемых действий (операций) и (или) действий (операций), выполняемых автоматически, они также включаются в паспорт функции.

Для неавтоматизируемых в централизованных компонентах АИС "Налог-3" технологических процессов ФНС России паспорта функций не разрабатываются.

1.4. При осуществлении переписки по вопросам разработки (доработки) паспортов функций необходимо указывать следующую информацию: код технологического процесса ФНС России, наименование паспорта функции, версию паспорта функции, статус паспорта функции, дату введения в действие статуса паспорта функции (далее - реквизиты паспорта функции).

1.5. Хранение паспортов функций со статусами "Рекомендован" (далее - эталонных экземпляров паспортов функций) и "Исключен", структурной схемы технологических процессов ФНС России и документа в электронном виде, содержащего информацию о паспортах функций и состоянии их разработки (доработки) (далее - реестр паспортов функций) осуществляет Межрегиональная инспекция ФНС России по централизованной обработке данных (далее - МИ ФНС России по ЦОД).

2. Порядок разработки (доработки) паспортов функций

2.1. При появлении нового технологического процесса ФНС России/изменении существующего технологического процесса ФНС России, подлежащего автоматизации в централизованных компонентах АИС "Налог-3", владелец технологического процесса ФНС России не позднее 10 рабочих дней после внесения изменений в Перечень технологических процессов ФНС России (далее - Перечень) или возникновения других оснований направляет в Управление модернизации налоговых органов (копия в МИ ФНС России по ЦОД) заявку на разработку/доработку паспорта функции согласно приложениям N 1 и N 2 к настоящему Регламенту, соответственно.

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

Владелец технологического процесса ФНС России включает в заявку на разработку/доработку паспорта функции информацию о необходимых показателях, по которым контролируется/оценивается выполнение процесса, в том числе (при необходимости), о нормативном времени выполнения процесса в целом и по отдельным операциям.

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

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

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

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

Срок окончания перехода на использование новой кодировки технологических процессов ФНС России - 31.12.2016.

2.3. При поступлении заявки, не соответствующей приложениям N 1 или N 2 к Регламенту, Управление модернизации налоговых органов не позднее 5 рабочих дней после поступления заявки направляет владельцу технологического процесса ФНС России (копию в МИ ФНС России по ЦОД) письмо об отказе в выполнении заявки.

2.4. При поступлении заявки, соответствующей требованиям Регламента, Управление модернизации налоговых органов определяет приоритетность разработки (доработки) паспорта функции и направляет Исполнителю, в Управление информационных технологий, МИ ФНС России по ЦОД, а также в порядке информирования владельцу технологического процесса ФНС России поступившую заявку в срок не позднее 5 рабочих дней после ее поступления с указанием определенной для нее приоритетности.

2.5. Исполнитель на основании заявки, поступившей от Управления модернизации налоговых органов, изучает нормативные правовые акты, другие документы, регламентирующие порядок выполнения технологического процесса ФНС России, фактический порядок выполнения технологического процесса ФНС России, в том числе в рамках организуемых и проводимых Исполнителем рабочих совещаний с участием сотрудников ФНС России, ее территориальных органов и подведомственных организаций, в соответствии с правилами, приведенными в приложении N 3, разрабатывает (дорабатывает) модель технологического процесса, формирует проект паспорта функции и направляет его владельцу технологического процесса ФНС России (копию в МИ ФНС России по ЦОД и Управление модернизации налоговых органов) в следующий срок:

не позднее 30 рабочих дней после поступления Исполнителю заявки - при разработке паспорта функции;

не позднее 15 рабочих дней после поступления Исполнителю заявки - при доработке паспорта функции.

2.6. При наличии объективных причин невозможности разработки (доработки) проекта паспорта функции в установленный Регламентом срок Исполнитель направляет запрос на изменение срока представления проекта паспорта функции (с указанием предлагаемого срока) владельцу технологического процесса ФНС России (копию в МИ ФНС России по ЦОД, Управление модернизации налоговых органов и Управление информационных технологий). Новый срок представления проекта паспорта функции устанавливается после подтверждения его владельцем технологического процесса ФНС России, при отсутствии возражений от Управления модернизации налоговых органов и Управления информационных технологий.

2.7. При поступлении от Исполнителя запроса (копия запроса направляется Исполнителем в МИ ФНС России по ЦОД и Управление модернизации налоговых органов) на предоставление информации, необходимой для разработки (доработки) паспорта функции, владелец технологического процесса ФНС России обеспечивает ее предоставление в срок не позднее 10 рабочих дней после поступления запроса.

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

2.9. Владелец технологического процесса ФНС России обеспечивает согласование проекта паспорта функции с совладельцами технологического процесса ФНС России, а также владельцами других технологических процессов ФНС России при наличии изменений, требующих доработки их паспортов функций, которые при этом должны не позднее 5 рабочих дней после поступления проекта паспорта функции обеспечить его согласование и не позднее 10 рабочих дней после этого направить заявки на доработку связанных с ним паспортов функций.

2.10. Не позднее 10 рабочих дней после поступления от Исполнителя проекта паспорта функции владелец технологического процесса ФНС России направляет Исполнителю (копию в МИ ФНС России по ЦОД и Управление модернизации налоговых органов) письмо о согласовании проекта паспорта функции или письмо с замечаниями (в том числе в части несоответствия правилам, приведенным в приложении N 3) и предложениями к проекту паспорта функции.

2.11. Не позднее 10 рабочих дней Исполнитель осуществляет устранение поступивших замечаний и реализацию предложений и направляет проект паспорта функции владельцу технологического процесса ФНС России (копию в МИ ФНС России по ЦОД и Управление модернизации налоговых органов).

2.12. Не позднее 5 рабочих дней после получения письма о согласовании проекта паспорта функции Исполнитель присваивает ему статус "Рекомендован" и направляет его и доработанную структурную схему технологических процессов ФНС России (в случае необходимости внесения в нее изменений) в МИ ФНС России по ЦОД, Управление модернизации налоговых органов, владельцу технологического процесса ФНС России и в Управление информационных технологий. Датой ввода в действие статуса признается дата письма о согласовании паспорта функции.

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

2.13. Не позднее 5 рабочих дней после поступления эталонного экземпляра паспорта функции, доработанного по заявке на доработку, МИ ФНС России по ЦОД направляет исполнителю государственного контракта по сопровождению прикладного программного обеспечения на текущий год (копию владельцу технологического процесса ФНС России, в Управление информационных технологий и Управление модернизации налоговых органов) запрос о возможности автоматизации в АИС "Налог-3" технологического процесса ФНС России согласно поступившему эталонному экземпляру паспорта функции в рамках сопровождения прикладного программного обеспечения и сроках реализации данных работ.

2.14. Исполнитель государственного контракта по сопровождению прикладного программного обеспечения не позднее 15 рабочих дней после получения запроса направляет в адрес Управления информационных технологий (копию владельцу технологического процесса ФНС России, в МИ ФНС России по ЦОД и Управление модернизации налоговых органов) заключение о:

возможности/невозможности реализации в АИС "Налог-3" технологического процесса ФНС России согласно эталонному экземпляру паспорта функции в рамках сопровождения прикладного программного обеспечения (при невозможности реализации - аргументированный ответ);

календарной дате срока реализации данных работ.

2.15. Если исполнитель государственного контракта по сопровождению прикладного программного обеспечения совпадает с Исполнителем, МИ ФНС России по ЦОД не направляет запрос в соответствии с пунктом 2.13 Регламента, а Исполнитель направляет заключение, указанное в пункте 2.14 Регламента, одновременно с направлением эталонного экземпляра паспорта функции, доработанного по заявке на доработку (в соответствии с пунктом 2.12 Регламента).

2.16. Владелец технологического процесса не позднее 5 рабочих дней после поступления заключения в соответствии с пунктами 2.14-2.15 при несогласии со сроками реализации направляет в Управление информационных технологий аргументированную позицию.

2.17. Оформление заявки на модификацию на основе заключения, поступившего в соответствии с пунктами 2.14-2.15, и заявок-обоснований на выполнение работ по развитию (модернизации) АИС "Налог-3" по вновь разработанным паспортам функций осуществляется в порядке, установленном Положением об организации выполнения работ по развитию (модернизации) и оказания услуг по сопровождению автоматизированной информационной системы Федеральной налоговой службы (АИС "Налог-3").

3. Внесение изменений в структурную схему технологических процессов ФНС России

3.1. Основаниями для внесения изменений в структурную схему технологических процессов ФНС России являются:

- внесение в Перечень изменений, затрагивающих отображаемые на структурной схеме технологические процессы ФНС России;

- согласование владельцем технологического процесса ФНС России разработанного/доработанного паспорта функции, в который внесены изменения в части входов или выходов соответствующего технологического процесса.

3.2. Не позднее трех рабочих дней после внесения в Перечень изменений, затрагивающих отображаемые на структурной схеме технологические процессы ФНС России, МИ ФНС России по ЦОД направляет Исполнителю (копия в Управление модернизации налоговых органов) поручение внести изменения в структурную схему технологических процессов ФНС России.

3.3. Не позднее 5 рабочих дней после получения поручения Исполнитель направляет актуализированную структурную схему технологических процессов ФНС России в МИ ФНС России по ЦОД (копия в Управление модернизации налоговых органов).

4. Порядок оформления паспортов функций и структурной схемы технологических процессов ФНС России

4.1. Исполнитель, приступив к разработке паспорта функции, статус паспорта функции устанавливает равным "Проект", версию - "10.0", дату введения в действие статуса устанавливает равную дате поступления заявки от Управления модернизации налоговых органов.

4.2. Исполнитель, приступив к доработке паспорта функции, статус паспорта функции устанавливает равным "Проект", увеличивает текущий номер версии 10.X (где X - может принимать значения от 1 до 99) на 1 единицу (X + 1), дату введения в действие статуса устанавливает равной дате поступления заявки от Управления модернизации налоговых органов.

4.3. После перевода в статус "Проект" до перевода в статус "Рекомендован" версия паспорта функции не изменяется. При переводе доработанного паспорта функции в статус "Рекомендован" предыдущая его версия переводится в статус "Исключен". Номера версий при переводе статусов в "Рекомендован" и "Исключен" не изменяются.

4.4. Паспорт функции формируется Исполнителем в формате, совместимом с Microsoft Word.

4.5. Структурная схема технологических процессов ФНС России формируется Исполнителем на основе эталонных экземпляров паспортов функций и Перечня.

4.6. В структурной схеме технологических процессов ФНС России указываются реквизиты эталонных экземпляров паспортов функций.

4.7. В структурной схеме технологических процессов ФНС России указывается дата ее формирования.

4.8. Структурная схема технологических процессов ФНС России может иметь несколько уровней агрегации, в том числе с учетом Перечня. Форма графического представления (способ визуализации) структурной схемы технологических процессов ФНС России, уровни агрегации и другие параметры согласовываются Исполнителем с Управлением модернизации налоговых органов.

4.9. Актуальная структурная схема технологических процессов ФНС России должна быть представлена Исполнителем в МИ ФНС России по ЦОД, Управление модернизации налоговых органов и Управление информационных технологий не позднее 30 рабочих дней после заключения с ним государственного контракта.

4.10. МИ ФНС России по ЦОД размещает структурную схему технологических процессов ФНС России на Интранет-портале ФНС России не позднее трех рабочих дней после ее получения.

5. Порядок ведения реестра паспортов функций

5.1. Ведение реестра паспортов функций осуществляется МИ ФНС России по ЦОД в электронном виде.

5.2. Реестр паспортов функций содержит следующие сведения:

код технологического процесса ФНС России;

владелец технологического процесса ФНС России;

сведения о состоянии и контрольных сроках разработки (доработки) паспорта функции;

реквизиты паспорта функции (с историей изменения);

ссылка на файл паспорта функции, размещенный в базе данных "Библиотека документов" (только для паспортов функций в статусах "Рекомендован" и "Исключен").

5.3. Внесение сведений в реестр паспортов функций осуществляется не позднее двух рабочих дней после поступления сведений в МИ ФНС России по ЦОД.

5.4. При получении эталонного экземпляра паспорта функции МИ ФНС России по ЦОД:

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

- проверяет наличие в разделе "Перечень изменений" корректных реквизитов оснований и писем о согласовании;

- в случае отсутствия ошибок размещает паспорт функции в базе данных "Библиотека документов" (ссылка на него вносится в реестр паспортов функций);

- в случае обнаружения ошибок направляет Исполнителю (копия в Управление модернизации налоговых органов) поручение в срок не позднее 5 рабочих дней внести необходимые технические изменения в паспорт функции.

5.5. При переводе паспорта функции в статус "Исключен" (в том числе, в связи с переводом в статус "Рекомендован" его новой версии или в связи с исключением технологического процесса ФНС России из Перечня) МИ ФНС России по ЦОД в базе данных "Библиотека документов" на титульном листе данной версии паспорта функции указывает статус "Исключен" и дату перевода в данный статус.

5.6. Не позднее трех рабочих дней после внесения в Перечень изменений МИ ФНС России по ЦОД:

- если изменяется код или уточняется наименование технологического процесса ФНС России, для которого существует эталонный экземпляр паспорта функции, без изменения относящихся к нему действий, направляет Исполнителю поручение в срок не позднее 5 рабочих дней внести необходимые технические изменения в эталонный экземпляр паспорта функции;

- если изменения затрагивают действия, относящиеся к технологическим процессам ФНС России, подлежащим автоматизации в централизованных компонентах АИС "Налог-3", в случае отсутствия соответствующих заявок на разработку/доработку паспортов функций направляет владельцам технологических процессов ФНС России письмо о необходимости представить в соответствии с пунктом 2.1 настоящего Регламента заявки на разработку/доработку паспортов функций.

5.7. Актуальные структурная схема технологических процессов ФНС России, реестр паспортов функций и эталонные экземпляры паспортов функций доступны для просмотра по ссылкам, размещенным на Интранет-портале ФНС России.

Приложение N 1
к Регламенту разработки
паспортов функций и ведения
реестра паспортов функций

Заявка на разработку паспорта функции

1. Наименование технологического процесса ФНС России:

2. Код технологического процесса ФНС России:
________________
Код технологического процесса ФНС России указывается в соответствии с Перечнем. В случае отсутствия технологического процесса ФНС России в Перечне, необходимо указать реквизиты письма, которым направлена Заявка на внесение изменений в Перечень о добавлении соответствующего технологического процесса ФНС России.

4. Нормативные правовые акты, приказы, планы, письма, разъяснения, методические рекомендации и т.п., а также поручения руководства ФНС России и других ведомств, устанавливающие порядок выполнения технологического процесса:

5. Начало выполнения технологического процесса (событие (действие) либо состояние, ведущее к началу выполнения технологического процесса):

6. Перечень входной информации для технологического процесса ФНС России (например: заявление физического лица о постановке на учет в налоговом органе, налоговая декларация по налогу на добавленную стоимость):

7. Источник входной информации (например: налогоплательщик, наименование внешней организации, наименование структурного подразделения налогового органа, код и наименование технологического процесса ФНС России):

8. Требуемый результат (перечень выходной информации, например: свидетельство о постановке на учет физического лица в налоговом органе, решение о возмещении полностью суммы налога на добавленную стоимость, заявленной к возмещению):

9. Потребитель выходной информации (например: налогоплательщик, наименование внешней организации или код и наименование технологического процесса, использующего результат технологического процесса ФНС России):

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

11. Текстовое описание порядка выполнения технологического процесса ФНС России:

Приложение N 2
к Регламенту разработки
паспортов функций и ведения
реестра паспортов функций

Заявка на доработку паспорта функции

1. Реквизиты паспорта функции, подлежащего доработке:

2. Основания для доработки, включая положения нормативно-правовых актов, организационно-распорядительных документов ФНС России, изменяющих порядок выполнения технологического процесса ФНС России:

3. Описание изменений технологического процесса ФНС России:

3.1. Начало выполнения технологического процесса ФНС России (событие (действие) либо состояние, ведущее к началу выполнения технологического процесса):

3.2. Перечень входной информации для технологического процесса ФНС России (например: заявление физического лица о постановке на учет в налоговом органе, налоговая декларация по налогу на добавленную стоимость):

3.3. Источник входной информации (например: налогоплательщик, наименование внешней организации, наименование структурного подразделения налогового органа, код и наименование технологического процесса ФНС России):

3.4. Требуемый результат (перечень выходной информации, например: свидетельство о постановке на учет физического лица в налоговом органе, решение о возмещении полностью суммы налога на добавленную стоимость, заявленной к возмещению):

3.5. Потребитель выходной информации (например: налогоплательщик, наименование внешней организации или код и наименование технологического процесса ФНС России, использующего результат технологического процесса ФНС России):

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

3.7. Текстовое описание необходимых изменений в порядок выполнения технологического процесса ФНС России:

Приложение N 3
к Регламенту разработки
паспортов функций и ведения
реестра паспортов функций

Правила описания технологических процессов ФНС России с использованием BUSINESS STUDIO

1. Основные принципы описания технологических процессов

1.1. Технологические процессы должны быть описаны в нотации Процедура. При этом используются типы процессов Решение и Действие. Тип процесса Событие не используется. Событие, которое запускает выполнение процесса, отражается в свойствах Процедуры в колонке Начало. Описание требований к заполнению свойств Процедуры дано ниже и представлено на рис.2.

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

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

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

1.5. Вся входная/выходная информация (включая БД, ИР, бумажные и электронные документы) должна быть предварительно описана в Справочнике объектов деятельности, при этом следует группировать ее по папкам в соответствии с приведенной в справочнике классификацией. Дополнение и изменение входной/выходной информации производит разработчик модели технологического процесса.

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

1.7. Нормативные документы (административный регламент, регламент ФНС, приказы, письма ФНС), регулирующие выполнение конкретного технологического процесса, должны быть включены в Справочник Объекты деятельности/Документы/Бумажныедокументы/Нормативно-справочныедокументы и указаны в свойствах технологического процесса (рис.1*).
________________

1.8. Входы/выходы от внешних субъектов должны начинаться/заканчиваться внешней ссылкой. Если технологический процесс связан с внешним субъектом несколькими входами/выходами, то входы/выходы могут быть изображены как отдельно, так и сгруппированы по правилам, описанным в Руководстве пользователя Business Studio.

________________
* Рисунок не приводится. - Примечание изготовителя базы данных.

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

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

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

1.12. Обязательными к заполнению являются следующие поля в свойствах технологического процесса (рис.2*):
________________
* Рисунок не приводится. - Примечание изготовителя базы данных.

1. Название;

3. Начало;

4. Субъекты (их может быть несколько, если технологический процесс однотипно выполняется на различных объектах организационной структуры ФНС России, например, в ИФНС и в УФНС, или в его выполнении участвуют несколько структурных подразделений объекта оргструктуры). Для каждого Субъекта необходимо определить тип связи (Владелец, Исполнитель или Участник) по следующим принципам:

- Владелец - это начальник структурного подразделения центрального аппарата ФНС России.

- Исполнитель - это структурное подразделение (ИФНС, УФНС, и т.п.) или отдел структурного подразделения, отвечающее за выполнение (результат) технологического процесса.

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

5. Нормативные документы. Порядок заполнения описан выше.

6. Термины и сокращения.

2. Диаграмма в нотации Процедура

2.1. Диаграмма Процедуры делится Субъектами на колонки, в которых размещаются Действия. Колонки Субъектов на диаграмме можно расположить горизонтально или вертикально (рекомендуется использовать вертикальное расположение). Субъекты на диаграмму процедуры добавляются перетаскиванием из иерархического справочника субъектов, который показывается в дереве Навигатора. Колонки внешним организациям не выделяются, т.к. логика выполнения их технологических процессов не описывается. Заменить добавленный ранее субъект на другой можно с помощью пункта меню "Действия рисунок (не приводится) Сменить субъект". В качестве Субъектов указываются отделы структурных подразделений (Отдел камеральной проверки и т.п.) или сами структурные подразделения (ИФНС, УФНС, и т.п.) в случаях трудности отнесения операций к конкретному подразделению.

2.2. Затем на диаграмме отображается последовательность операций в рамках данного технологического процесса в соответствии с наложенной "сеткой ответственности". Каждое действие помещается в дорожку субъекта, который его выполняет. При этом автоматически создается связь процесса с субъектом с типом "выполняет". При перемещении действия из дорожки одного субъекта в дорожку другого субъекта значение этой связи изменяется. Если в свойствах действия на закладке "Субъекты" заменить субъект с типом связи "выполняет" на другой, то на диаграмме вышележащей процедуры действие переместится из дорожки, где оно находилось, в дорожку выбранного субъекта или за рамку процедуры, если выбранного субъекта нет на диаграмме.

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

2.4. На диаграммах процессов можно добавлять только стрелки типа "Связь предшествования" (Добавление осуществляется с помощью кнопки рисунок (не приводится) Использовать стрелки типа "Поток объектов" (кнопка типа рисунок (не приводится) не допускается.

2.5. "Связь предшествования" - обозначает передачу управления от одного действия к другому, т.е. предыдущее действие должно закончиться прежде, чем начинается следующее. Обозначается стрелкой с одним треугольником. Если стрелка служит только для обозначения передачи управления, то имя стрелки оставляется пустым. Если кроме передачи управления из предыдущего действия в следующее действие поступают Объекты, то стрелка именуется и в список объектов стрелки заносится соответствующие Объекты.

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

3. Формирование отчета "Паспорт функции"

После завершения описания технологического процесса по нему формируется отчет "Паспорт функции" в соответствии с требованиями Регламента разработки паспортов функций и ведения реестра паспортов функций (далее Регламент), а именно, документ должен быть сформирован в формате Microsoft Word.

4. Правила кодировки процессов/процедур/действий

4.1. Для управления порядком следования процессов/действий в таблицах отчетов используется ручная кодировка.

4.2. Правила присвоения кодов процессам/действиям:

- на каждом уровне для кодирования используются два знака;

- указание лидирующих нулей обязательно.

4.3. Код процесса/действия указывается перед его наименованием и является частью этого имени.

4.4. Признак ручной кодировки устанавливается в свойствах модели в окне "Редактирование объекта из Параметры модели" следующим образом (рис.2а*):
________________
* Рисунок не приводится. - Примечание изготовителя базы данных.

- опция "Использовать код в названии" должна быть выключена;

- признак "Тип кода процесса" изменен на "Ручной".

5. Выделение действий в технологическом процессе

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

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

5.3. Основой разбиения является принадлежность этого действия к одному из архитектурных блоков транзакционного сегмента ФХД АИС "Налог 3", который отвечает за обеспечение процесса налогового администрирования в рамках ФНС России:

- Налоговый автомат

- Пользовательское задание

- Интерактивная работа

5.4. Принадлежность действий к одному из архитектурных блоков указывается в их свойствах путем привязки к соответствующей строке справочника Программные продукты раздела Объекты деятельности (рис.3*).
________________
* Рисунок не приводится. - Примечание изготовителя базы данных.

6. Порядок ведения версий описания технологических процессов

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

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

6.4*. Учет всех изменений, внесенных в технологический процесс, ведется с использованием инструмента версионности модели ("Совместная работа" "Сменить статус процесса").
_______________

* Нумерация соответствует оригиналу. - Примечание изготовителя базы данных.

6.5. Параметры версии:

- Версия процесса;

- Редакция версии процесса;

- Статус процесса.

6.6. Основанием для изменения версии является завершение работ по очередному этапу описания технологического процесса. Номер версии процесса (версии паспорта функции) устанавливается в соответствии с Регламентом.

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

6.8. При заполнении поля Изменения в дополнение к описанию произведенных доработок необходимо указывать реквизиты документа-основания (дату и номер письма заказчика).

________________
* Рисунок не приводится. - Примечание изготовителя базы данных.

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

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

1. Размещение соответствующего термина в справочнике "Термины" "Глоссарий" "Термины и определения". Операция выполняется лицом, ответственным за описание технологического процесса.

________________
* Рисунок не приводится. - Примечание изготовителя базы данных.

________________
* Рисунок не приводится. - Примечание изготовителя базы данных.

- При заполнении справочника осуществляется работа с двумя параметрами свойств терминов - "Название" и "Комментарий". В параметр "Название" вводится название термина, в параметр "Комментарий" - его определение.

- Ведение справочника "Сокращения" ("Термины" "Глоссарий" "Сокращения") аналогично ведению справочника "Термины и определения": в поле "Наименование" указывается аббревиатура, в поле "Комментарий" вводится расшифровка аббревиатуры.

- Организация дополнительных папок внутри Глоссария не допускается.

2. Формирование перечня терминов и сокращений, используемых при описании функции/технологического процесса.

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

- Перед началом работы добавляется закладка "Термины и сокращения" в свойства функции с использованием пункта меню "Настройка закладок".

________________
* Рисунок не приводится. - Примечание изготовителя базы данных.

________________
* Рисунок не приводится. - Примечание изготовителя базы данных.

- Формирование перечня производится путем добавления в список "Термины и сокращения" соответствующих элементов справочников "Термины и определения" и "Сокращения".

________________
* Рисунок не приводится. - Примечание изготовителя базы данных.

В таблице 1 приведены основные параметры процессов и их правила заполнения.

Таблица 1


Параметр	Описание	Правила заполнения
Код процесса	Код процесса состоит из префикса модели и числового кода, отражающего место процесса в общей модели процессов (ветвь иерархического дерева процессов и уровень иерархии).	Устанавливается автоматически для всех процессов. Может устанавливаться вручную.
Название	Название процесса.	Название процесса должно быть активным глаголом, глагольным оборотом или отглагольным существительным.
	Описание деятельности, осуществляемой в рамках процесса, в текстовой форме.	Текст должен начинаться со строчной буквы и являться продолжением фразы: "Содержанием деятельности по процессу является...". Точка в конце не ставится.
	Событие (действие) либо состояние, ведущее к началу выполнения процесса. Параметр необходимо заполнять для процессов, описанных в нотациях Процесс, Процедура.	Текст должен начинаться со строчной буквы и являться продолжением фразы: "Началом выполнения процесса (процедуры) является...". Точка в конце не ставится.
Результат	Текстовое описание основного результата процесса. Т.к. процесс может иметь несколько результатов, для целей регламентации необходимо указать основной результат.	Текст должен начинаться со строчной буквы и являться продолжением фразы: "Основным результатом процесса (процедуры) является...". Точка в конце не ставится.
Требования к срокам	Требования к срокам выполнения процесса.	Текст должен начинаться с прописной буквы. В конце ставится точка.

Последовательная декомпозиция целей

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

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

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

Полнота "дерева целей" и соответствие рангов подцелей. Полнота "дерева целей" обеспечивается путем:

1) разбиения исходной цели или очередной промежуточной подцели
п-то ранга на наиболее укрупненные, однородные составляющие подцели
(л+1)-го ранга. Обычно удается выделить от 2 до 5 таких подцелей;

2) если нет уверенности, что они полностью исчерпывают разделяе
мую (декомпозируемую) подцель старшего n-го ранга, то, кроме выделен
ных, следует ввести еще одну (резервную) подцель (n+1)-го ранга, содер
жащую "прочие", т.е. неучтенные, подцели. При дальнейшей проработке
проблемы такие "прочие" составляющие будут либо конкретизированы,
либо исключены из состава "дерева целей".

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

Проверка соответствия рангов подцелей состоит в следующем: из выделенных подцелей (n + 1)-го ранга надо попытаться найти две или несколько таких, которые можно объединить по некоторому общему принципу, но в то же время к этому объединению нельзя отнести остальные подцели. Если такая попытка увенчается успехом, это будет означать, что однородность подцелей нарушена и требуется корректировка рангов подцелей (подробнее см. ).

Хороших результатов по полноте выявления подцелей и соответствию их рангов удается достигнуть, привлекая к составлению "дерева целей" нескольких специалистов (экспертов), каждый из них строит "дерево" самостоятельно, а затем участвует в совместном обобщении и уточнении результатов.

Обобщая процесс формирования целей, можно сделать следующие выводы:

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

¨ результаты декомпозиции удобно фиксировать в виде "дерева целей", которое оформляется либо в виде графа иерархической структуры, либо в виде таблицы, строки которой определяют место подцели в иерархии;

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

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

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

Даже для одного предприятия может быть построено несколько вариантов "дерева".

Используя ранее изложенную методологию, построим "дерево целей" для химического предприятия с широким ассортиментом продукции (рис. 4.5). Зададим цель - максимальное повышение эффективности предприятия. Целевую функцию максимального повышения эффективности деятельности предприятия можно представить в виде двух основных групп подцелей: подцель 1 - достижение конечных результатов (у j); подцель 2 - экономия ресурсов всех видов (х j).

Очевидно, каждую из этих групп можно рассматривать как одну из двух основных подцелей (т.е. подцелей 1-го ранга).

В свою очередь, среди конечных результатов выделим результаты ос-вной деятельности системы (по производству продукции, услуг, информации) и результаты решения социальных задач. Каждую из этих групп ДЦелей можно рассматривать как подцель 2-го ранга:

подцель 1.1 -- удовлетворение потребности в продукции и услугах;

подцель 1.2 - достижение социальных целей.

Со своей стороны, другая подцель 1-го ранга (экономия ресурсов всех лов) может быть также разбита на две или несколько подцелей 2-го ранга. Например, на экономию текущих (регулярных) затрат, измеряемых как правило, в рублях в год, и экономию единовременных затрат, измеряемых в рублях:

подцель 2.1 - экономия текущих затрат, снижение потерь;

подцель 2.2 - экономия единовременных затрат.

Развиваем "дерево целей" предприятия, последовательно расчленяя четыре подцели 2-го ранга, представленные на рис. 4.5.

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

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

Подцель 1.1.2 - удовлетворение потребности по качеству продукции целесообразно сразу же разделить на две подцели: обеспечение качества в пределах, установленных нормативно-техническими документами, и повышение качества в соответствии с экономически обоснованной потребностью.

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

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

подцель 1.1.3.1 - обеспечение ритмичности поставок продукции;

подцель 1.1.3.2 - ускорение реакции производства на изменение спроса. Дальнейшее дезагрегирование указанных подцелей зависит от поставки анализируемой проблемы и конкретных условий ее решения.

Подцель 1.2 - достижение социальных целей. Здесь правомерно сразу выделить две крупных группы целей: экологические и локальные, отно-яеся к социальному развитию коллектива предприятия.

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

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

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

Вспомните, что SADT-аналитик делает набросок декомпозиция, подвергает его критической оценке, перечерчивает и затем выпускает соответствующую папку. Эта глава состоит из трех уроков, связанных с созданием декомпозиции первого уровня - т.е. декомпозиции блоков диаграммы АО. В уроке 8 создается диаграмма, декомпозирующая один блок диаграммы АО. Урок 9 - авторская критика и пересмотр диаграммы. В уроке 10 рассматривается процесс создания папки для рецензирования.

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

урок 8. Групповое построение диаграмм

Цель

Выбрать и декомпозировать один из блоков диаграммы АО.

Действия

1. Выберите блок диаграммы АО. Этот блок является контекстным на протяжении всего этого урока. Не выходите за его границы.

2. Мысленно проверьте этапы построения диаграммы: составить список объектов, составить список функций, сгруппировать функции в 3-6 блоков, начертить блоки в порядке убывания доминантности; начертить внешние дуги, начертить дуги управления, начертить входные и выходные дуги.

3. Прочтите диаграмму АО снова, сосредоточившись на том, как ваш блок согласуется с другими блоками. Используйте граничные дуги выбранного вами блока для начала составления списка данных.

4. Выполните остальные этапы создания диаграммы. Старайтесь разместить списки данных и функций в левой части бланка, а чертить диаграмму - в правой части (это не более чем совет).

5. При вычерчивании делайте для себя примечания и определяйте терминологию.

6. После окончания работы проверьте ICOM-коды. Удостоверьтесь, что вы не забыли использовать граничные данные.

Примечания

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

2. На данном этапе не беспокойтесь о корректности этой диаграммы. Декомпозиции данного уровня редко удаются с первого раза.

Образец

1. Обратите внимание на то, что сначала перечислены внешние входные дуги, дуги управления и выходные дуги, а затем -последующие данные, составляющие компоненты этих дуг. Так вы будете уверены, что не забыли контекст, в котором работаете.

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

урок 9. Критическая оценка декомпозиции первого уровня

Цель

Критически исследовать построенную в уроке 8 диаграмму, чтобы определить, как она детализирует родительский блок диаграммы АО.

Действия

1. Просмотрите построенную диаграмму и попытайтесь изложить то, как она отражает свою часть задачи питания семьи. Начните с логического начала: с поступления одного или более объектов из блока диаграммы АО. Обращайтесь непрерывно к диаграмме АО и делайте примечания, когда находите изложение неверным или неполным.

3. Не забывайте отмечать нужные изменения как на вашей диаграмме, так и на диаграмме АО. Изменяйте или уточняйте вашу терминологию в процессе критического анализа.

4. Постройте видоизмененную в соответствии с вашими замечаниями диаграмму и перечертите, если необходимо, диаграмму АО. Не забывайте проверять ICOM-связи между рассматриваемой диаграммой и диаграммой АО.

Примечания

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

Образец

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

2. Блок составить список покупок сделан более общим.

Это означает, и что теперь функция Спланировать покупки управляет еще и выбором магазинов.

3. Замечание 4 напоминает, что необходимо уточнить вместе с автором, который ввел в диаграмму функцию

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

часто бывают, когда модель строится несколькими авторами.

урок 10. Подготовка папки

Цель

Собрать в SADT-папке проверенную вами диаграмму первого уровня и связанный с ней глоссарий.

Действия

1. Подготовьте как вашу диаграмму, так и глоссарий и проверьте согласованность информации.

2. Оформите титульный лист: внесите в него идентифицирующую информацию (автор, проект, дата), название папки, а также укажите, что она содержит, кому должна быть направлена и когда возвращена.

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

4. Скрепите страницы - сначала титульный лист, затем диаграмму АО, потом вашу диаграмму и, наконец, глоссарий. После этого пошлите папку библиотекарю проекта.

Примечания

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

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

Образец

1. В помещенном на титульном листе примечании содержится просьба к читателям определить термин информация о реальном количестве продуктов. Обратите внимание, как это затруднение отмечено в глоссарии.

2. Запасы, маршрут и список покупок определены в глоссарии через перечисление составляющих их частей.

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

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

Например, стандартный персональный компьютер начала 21в. состоит из системного блока, монитора, клавиатуры, мышки и проводов, которые соединяют эту систему. Системный блок – это материнская плата, процессор, кулер, винчестер и т.д. Мышка – это датчик перемещения, управляющие элементы, интерфейс подключения к компьютеру. Управляющие элементы мышки – это правая и левая кнопки, колёсико, дополнительные кнопки.

Декомпозиция системы чаще всего представляется в виде иерархического дерева, вершина которого — сама система, а уровни — выделенные подсистемы.

Подобные иерархические деревья для приложений можно строить с целью:

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

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

· при создании чеклистов или тест-кейсов

· при выполнении тестирования исследовательским способом

· при проведении тестирования требований

· при планировании и оценке задач по тестированию

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

Признаки декомпозиции

Для разделения одного и того же приложения на подсистемы могут использоваться разные признаки декомпозиции. В качестве задачи на декомпозицию мы будем рассматривать приложение «Браузер» (см. рис. 1). Следует учесть, что во всех примерах, которые будут приведены ниже, декомпозиция не полная. Показаны лишь некоторые из подсистем первого и второго уровней.

Рис. 1. Скриншот приложения «Браузер»

В качестве признака разделения приложения могут использоваться:

внешний интерфейс (экран, окно, закладка и т.п. со всеми элементами интерфейса). На рис. 2 показан пример декомпозиции по этому признаку.
компонентная структура (функциональные модули приложения и их интеграция в более сложные модули). См. пример на рис. 3.
функции приложения и их варианты использования (см. пример на рис. 4),
обрабатываемые приложением объекты и данные (и часто нужно анализировать не то, что видно, а то что скрыто внутри — что передается на вход, что на выходе, что храниться внутри системы),
характеристики (параметры) объектов и данных или в целом всей системы (например, если объект — это файл, то параметры это — формат, размер, создатель, дата создания и т.д.),
действия над объектами (если объект «файл», то действия — удалить, переименовать, переместить, а если объект «список файлов», то действия — сортировать, фильтровать, выделить несколько файлов)
состояния, в которые переходит приложение или его модули,
этапы взаимодействия пользователя с приложением (см. пример на рис. 5),
виды пользователей,
характеристики качества (функциональность, удобство использования, производительность и т.д.),
и другие.

Рис. 2. Пример декомпозиции по элементам интерфейса приложения «Браузер»

Рис. 3. Пример компонентной декомпозиции приложения «Браузер»

Рис. 4. Пример функциональной декомпозиции приложения «Браузер»

Рис. 5. Пример декомпозиции по этапам взаимодействия пользователя с приложением «Браузер»

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

Принципы декомпозиции

1. Каждое разделение образует свой уровень.

Исходная система располагается на нулевом уровне. После её разделения получаются подсистемы первого уровня. Разделение этих подсистем или некоторых из них приводит к появлению подсистем второго уровня и т.д.

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

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

3. Вычленяемые подсистемы в сумме должны составлять всю систему (как пазл соединяться в одну картинку). При этом они должны взаимно исключать друг друга.

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

В процессе декомпозиции допускается выделять группу (подсистему) «Другие», в которую включаются те подсистемы, для которых невозможно выделить один общий признак или подсистем получается слишком много, чтобы выделять их на верхний уровень. Но в «Других», должен всё равно применяться некий свой внутренний признак расчленения.

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

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

Глубина декомпозиции (количество уровней) и степень подробности описания определяются требованиями обозримости и удобства восприятия получаемой иерархической структуры, её соответствия уровням знания работающему с ней специалисту.

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

Раньше рекомендовалось выделять 3-6 уровней. В настоящее время существует специальное ПО для создания интеллектуальных карт и управлять декомпозицией стало проще. Однако всё равно следует искать золотую середину, подходящую под ваши условия работы, и учитывать, что когда в структуре получается много уровней, то система становится труднообозримой, в ней сложно ориентироваться. Если же глубину делать небольшую, то вероятнее всего возрастет число находящихся на одном уровне подсистем и становится сложно связать их в единую полную систему, сложно искать взаимосвязи.

Системы нижнего уровня называются элементарными.

Если иерархическая схема используется как чеклист, то элементарные системы — это и есть идеи тестов.

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

5. Проводите критическую оценку декомпозиции каждого из построенных уровней и системы в целом.

Всё ли охвачено? Не пропущено ли? Может быть есть избыточные ветви или пересекающиеся?

Понятно ли как тестировать системы нижнего уровня? Можно ли расчленить эти системы еще больше? Если ваших знаний недостаточно для дальнейшей декомпозиции, то привлекайте других участников проекта (проектных менеджеров, программистов и т.д.)

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

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

Структурная декомпозиция работ проекта

Успешное управление проектом зависит от способностей менеджера эффективно руководить командой проекта, достигая спланированных результатов. Если в документе «Паспорт проекта» сопоставить разделы «Продукт проекта» и «Результаты проекта», станет очевидно, что результатами проекта являются элементы декомпозиции продукта проекта. Именно поэтому при формировании плана выполнения проекта используют структурную декомпозицию работ. Существует несколько различных русскоязычных названий (англоязычный термин только один), которые, по сути, отражают одно и то же – структурная декомпозиция работ, структура декомпозиции работ, иерархическая структура работ, структура разбиения работ.

Структурная декомпозиция работ (СДР или WBS - Work Breakdown Structure) – это представление проекта в виде иерархической структуры работ, полученной путем последовательной декомпозиции. СДР предназначена для детального планирования, оценки стоимости и обеспечения персональной ответственности исполнителей.

Благодаря структурной декомпозиции работ менеджер проекта имеет:

· точное описание содержания работ;

· точное определение объема работ;

Предназначение СДР

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

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

Разработка СДР имеет две основные цели :

1. обеспечение планирования всех необходимых работ проекта,

2. обеспечение отсутствия работ, не связанных с реализацией проекта.

Для руководителя проекта важны обе эти цели. Если в плане отсутствуют необходимые работы, проект будет задержан, бюджет, скорее всего, будет превышен. Если выполняются работы, не относящиеся к данному проекту – деньги заказчика тратятся нецелевым образом. Если СДР не объединяет обе эти цели, проект может потерпеть неудачу.

На основе СДР выполняются следующие процесс:

1. определение работ,

2. планирование ресурсов,

3. оценка стоимости,

4. бюджетирование,

5. определение рисков.

Рис. 2‑1 Взаимодействие СДР с процессами реализации проекта (PMBOK Guide 1996)

Таким образом, СДР является основой:

Комплексного план-графика проекта

программных продуктов

· Отчетности о выполнении проекта – с помощью СДР определяется состояние проекта и выдается в различные формы отчетности. Например, по стадиям жизненного цикла проекта; по результатам; по пакетам работ. Отчеты могут содержать данные по стоимости, срокам, рискам, объему, трудоемкости и качеству выполняющегося проекта или по сравнению с предыдущими аналогичными проектами (с такой же структурой).

Комплексного контроля изменений

Управления содержанием проекта

Организации взаимодействия между участниками проекта

Формирования организационной структуры

определенных сроков

Разработка структурной декомпозиции работ

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

Провести декомпозицию и составить СДР, по мнению некоторых авторов, очень легко: «Прежде всего, следует разбить проект на несколько подпроектов. Каждый из подпроектов, в свою очередь, может быть разбит на некоторое число подподпроектов. Так следует последовательно делить проект на составные части до тех пор, пока не будет достигнут нижний уровень детализации».

На самом деле, все не так однозначно. На стадии инициации проекта руководитель должен ответить на целый ряд вопросов:

· Что нужно сделать (определить продукты проекта);

· как это нужно будет делать (определить технологические этапы проекта);

· кто это будет делать (определить исполнителей, соисполнителей, субподрядчиков);

· кто и в какой форме будет оплачивать работы (определить, какие и с кем будут заключены контракты).

На какие подпроекты нужно разбить исходный проект? Что будет удобнее увидеть на первом уровне декомпозиции – компоненты конечного продукта проекта (программные, технические, информационные) или технологические этапы производства (концепция, ТЗ, проектирование)? А может быть, удобнее сгруппировать работы по исполнителям или заказчикам? Таким образом, мы подошли к трем вариантам построения СДР:

1. продуктовый подход – построение СДР по компонентам продукта проекта, когда в качестве элементов СДР выбираются элементы продукта проекта, его материальные результаты.

https://pandia.ru/text/80/308/images/image003_93.gif" width="675 height=526" height="526">

3. организационный подход – построение СДР по компонентам организационной структуры, когда в качестве элементов СДР выбираются элементы структурной схемы организации.

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

Рисунок – Декомпозиция работ по различным основаниям.

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

Системный подход к СДР

Если при разработке СДР руководствоваться теорией управления системами, то можно рассматривать проект как процесс превращения входных элементов (ресурсов, денег, трудозатрат) в выходные (результаты проекта).

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

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

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

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

Этапы разработки СДР

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

Основной процесс разработки СДР состоит из следующих шагов:

Первый шаг

определение конечных результатов проекта

Второй шаг

определение основных пакетов работ

Третий шаг

Четвертый шаг

анализ и усовершенствование СДР.

Подготовку структуры декомпозиции работ (СДР) можно считать законченной, когда определены мелкие индивидуальные части (элементарные) работы. Ответственность за каждую элементарную работу должна быть поручена одному и только одному члену команды проекта. Очень важно понять, что первоочередная задача составления СДР – разделить проект на подпроекты до той степени детализации, когда появится возможность распределить элементарные работы.

Если проект большой, СДР может иметь довольно общий характер. Можно остановиться на самом нижнем уровне, который отслеживает руководитель проекта. Этот уровень, напомним, принято называть пакетом работ. Следует учитывать, что, начиная с этого уровня, другие менеджеры, занятые на проекте, должны осуществить более подробное разделение проекта на части (подпроекты) до уровня элементарных работ.

На самом нижнем уровне СДР должно быть описание элементарной работы, которая может быть выполнена одним человеком (или группой людей). Если этот человек (или группа) собираются выполнять работу, а не руководить ее выполнением, этот уровень может быть признан самым нижним уровнем СДР.

Правила разработки СДР

При разработке СДР необходимо принимать во внимание следующие основные правила :

· Каждый элемент СДР должен обеспечивать достижение измеримого результата.

· Каждый элемент СДР должен агрегировать все подчиненные элементы.

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

· Результаты пакетов работ должны быть уникальными.

· Выполнение отчетов должно быть оформлено как выполнение отдельных пакетов работ.

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

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

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

Сложности, связанные с разработкой СДР:

Нахождение баланса между детализацией проекта и требованиями к сбору фактической информации и отчетности (излишняя детализация).

Разработка элементов СДР

организационную структуру

без учета промежуточных результатов проекта (недостаточная детализация)

Недостаточное внимание к разработке СДР и переход непосредственно к формированию сетевого графика

критического пути

Определение необходимости в дальнейшей детализации

В учебно-справочной литературе по управлению проектами для проектов средней сложности рекомендуется использовать до 6 уровней СДР: 3 верхних уровня для предоставления информации уровня заказчика, 3 нижних уровня для детализации информации уровня исполнителя. Глубина детализации СДР зависит от размера и сложности проекта, поскольку должна обеспечивать четкую формализацию целей и результатов работы, которые необходимо выполнить. Каждый пакет работ включает весь объем работ, выполняемый основной организацией, ответственной за данный пакет работ, так же, как и организациями, с которыми заключены подрядные договора.

Дальнейшая детализация необходима , если:

· Необходимо повысить точность оценки стоимости и длительности работ;

· Для пакета работ определен более чем один ответственный;

Объем работ, выполняемый в рамках данного пакета, описывает больше одного результата проекта; Необходимо раздельно определить стоимость процессов или результатов, описанных в данном пакете работ; Есть зависимость между работами внутри разных пакетов; Есть существенные перерывы в выполнении работ в рамках пакета; Меняются требования к ресурсам в течение времени в рамках пакета работ; Различаются исходные условия для работ внутри пакета работ; Существуют риски, связанные с частью пакета работ; Для части пакета работ может отдельно пересчитываться расписание.

Как было определено ранее, уровень детализации СДР зависит от размера и баланса между сложностью, риском, и требованиями руководителя проекта к контролю проекта. Уровень детализации может также изменяться в процессе жизненного цикла проекта. Для краткосрочных проектов на начальной стадии можно разработать всю СДР до достаточного уровня детализации, в то время как долгосрочные проекты и проекты с высоким уровнем сложности могут не декомпозироваться полностью на начальной стадии. Полностью СДР для таких проектов можно описать в процессе их реализации. С другой стороны, это может означать, что для конкретного проекта отдельные пакеты работ могут иметь различные уровни детализации. В частности, это верно при разработке «развертывающихся» проектов, когда план детализируется для работ, которые должны непосредственно начаться, а работы будущих периодов определяются укрупненно, на верхнем уровне, до тех пор, пока на более поздней стадии жизненного цикла проекта можно будет прописать их более детально.

Что является результатом декомпозиции 1 уровня. Иерархическая декомпозиция работ. Системный подход к СДР

Приложение N 1

Приложение N 2

Последовательная декомпозиция целей

урок 8. Групповое построение диаграмм

урок 9. Критическая оценка декомпозиции первого уровня

урок 10. Подготовка папки

Признаки декомпозиции

Принципы декомпозиции

Структурная декомпозиция работ проекта

Предназначение СДР

Разработка структурной декомпозиции работ

Системный подход к СДР

Этапы разработки СДР

Правила разработки СДР

Сложности, связанные с разработкой СДР:

Определение необходимости в дальнейшей детализации

Должностная инструкция капитана плавучего судна

4 95 сибид издания выходные сведения