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

ПРИКАЗ

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

приказываю:

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 в рамках 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, полноту и отсутствие избыточности предлагаемого наименования технологического процесса ФНС России (класса, подкласса, группы), отсутствие пересечений указанной деятельности с другими технологическими процессами ФНС России и вносит изменения в Перечень или направляет мотивированный отказ.

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

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

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

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

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

Наименование должно выражать действие и не превышать 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) Всегда должна быть соблюдена уровневая система.

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

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

Руководствуясь простой формальной алгеброй и логикой можно также строить «деревья И» и «деревья ИЛИ».

2) Расчленение целого на части должно происходить только по одному признаку.

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

В качестве признака можно использовать также временные рамки (сроки), предметные характеристики, структурные признаки, технологические характеристики и другие.

3) Все подсистемы декомпозиции должны раскрывать суть системы.

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

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

4) Глубина декомпозиционной проработки должна быть определена на начальном этапе.

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

Классификация

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

Как правило, все перечисленные процессы взаимосвязаны и в целом представляют полную декомпозиционную структуру.

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

Анализ действий

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

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

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

Классический прием

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

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

Применение в бизнесе

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

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

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

• общая пояснительная записка;
• архитектурные решения;
• конструктивные и объемно-планировочные решения.

• система электроснабжения;
• система водоснабжения;
• система водоотведения;
• отопление, вентиляция и кондиционирование воздуха, тепловые сети;
• сети связи;
• система газоснабжения;
• технологические решения.

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

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

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

Коротко о главном

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

Напомним, что блочная структура модели явилась результатом блочного представления содержательного описания, которое сфор­мировано объединением функционально связанных элементов. Поэтому соответствующий блок модели представляет собой сово­купность взаимосвязанных элементарных моделей, имитирующих работу таких функционально связанных элементов. Так, блок I (см. рис.3, б) в составе модели АСУ может представлять собой модель ЭВМ, а его элементы 12, 13, 26, 27 - модели процессора, основной памяти, канала обмена и внешнего устройства соответственно. Рас­смотрение перечисленных узлов как элементов говорит о том, что в данном примере уровень функциональной детализации (или степень декомпозиции) соответствует устройствам машины, поскольку по определению элемент есть часть системы, не подлежащая дальнейшему делению при данном уровне рассмотрения.

Чем же определяется выбор уровня рассмотрения? Можно ука­зать, по крайней мере, три фактора: 1) цели исследования; 2) имеющиеся в наличии исходные данные; 3) доступные ресурсы моделирования.

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

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

Процедуре декомпозиции системы соответствует переход от модели k-го уровня к множеству моделей (k + 1)-го уровня. При этом, как видно из соотношений (1.1), (1.2), возникает необходимость в дополнительных сведениях, которые отсутствовали в описании модели k-го уровня. Часто их не удается получить и при ее исследовании. Например, пусть требуется построить модель АСУ. После ее декомпозиции возникает задача построения моделей источников информации АСУ, средств передачи данных (СПД), средств переработки информации (СПИ), оператора и исполнительных средств. Чтобы смоделировать систему в целом, необходимо знать параметры потоков на входах и выходах этих средств. Для получения таких данных, например, для связи СПД - СПИ может появиться необходимость изучить действие помех с учетом типа линии, структуры передаваемых сообщений и способов повышения достоверности. Это более высокий (k+1)-й уровень детализации.

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

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

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

Третий фактор всегда выступает в качестве ограничения на степень детализации. К ресурсам моделирования следует отнести допустимые затраты труда, времени и денег, а также машинное время и объем памяти моделирующей ЭВМ Все они подлежат экономии, а при усложнении модели их затраты увеличиваются. Это объясня­ется тем, что повышение уровня детализации приводит к уменьше­нию «размера» элементов с одновременным увеличением их числа и количества взаимосвязей. Кроме того, увеличивается разрешение во временной области (уменьшается интервал между точками анализа траектории элемента). Так, если при построении простой мо­дели, отражающей работу ЭВМ на уровне устройств и имитирующей прохождение отдельных задач, для накопления статистики по тысяче задач требуется около 3 минут работы программы на языке GPSS, то при попытке фиксировать на той же модели события, длительность которых измеряется миллисекундами, время решения возрастает более чем в 50 раз, увеличиваются также и затраты па­мяти. Возможность выделения таких ресурсов на практике всегда ограничена.

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

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

Таблица 1

*АПД - аппаратура передачи данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Структурная декомпозиция работ (СДР или 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 нижних уровня для детализации информации уровня исполнителя. Глубина детализации СДР зависит от размера и сложности проекта, поскольку должна обеспечивать четкую формализацию целей и результатов работы, которые необходимо выполнить. Каждый пакет работ включает весь объем работ, выполняемый основной организацией, ответственной за данный пакет работ, так же, как и организациями, с которыми заключены подрядные договора.

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

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

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

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

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