Управление требованиями пользователей при разработке СЭД: собираем, анализируем, используем

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

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

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

Во время работы на любом проекте неизбежно возникает большое количество разнообразных пожеланий к функционалу системы. Как же справиться с этим потоком запросов?

Чтобы обработать и использовать требования с максимальной выгодой необходимо их:

  • выявить;
  • собрать;
  • зафиксировать;
  • проанализировать;
  • максимально полезно использовать при подготовке документов.

Виды требований,  порядок их поступления

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

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

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

Функциональные требования (FEAT-Functional Requirements) – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований.

Нефункциональные требования (BR-Business Rules) – определяют критерии работы системы в целом, а не отдельные сценарии использования. Нефункциональные требования описывают цели и атрибуты качества, ограничения.  Содержат или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами, учетными практиками, алгоритмами вычислений и т.д. Они могут определять такие свойства системы в целом как производительность, удобство сопровождения, расширяемость, надежность, условия эксплуатации.

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

Сценарий использования, вариант использования, прецедент или же пользовательский сценарий (англ. Use Case) — в разработке программного обеспечения и системном проектировании это описание поведения системы, которым она отвечает на внешние запросы. Другими словами, сценарий использования описывает, «кто» и «что» может сделать с рассматриваемой Управление требованиями пользователей при разработке СЭД: собираем, анализируем, используемсистемой.

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

UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это — открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем.

BPMN (англ. Business Process Model and Notation, нотация и модель бизнес-процессов)  — система условных обозначений (нотация) для моделирования бизнес-процессов. Последняя версия — 2.0.

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

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

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

Другой вариант фиксирования требований, получивший популярность в последнее время в связи с использованием методологии SCRUM – это User Story.

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

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

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

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

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

Таким образом, можно выделить следующие виды требований:

  • Запросы пользователей (STRQ - Stake Holder Request) – первичное описание запросов, поступивших от бизнес-пользователей.
  • Требования к системе (FEAT) – функциональные требования к системе.
  • Сценарий использования (BUC - Busyness Use Case) – описание последовательности действий, которые может осуществлять система в ответ на внешние воздействия пользователей или других программных систем.
  • Элементы словаря (GLS - Glossary) – определение терминов, используемых при определении требований.
  • Нефункциональные требования (BR - Business Rules) – требования к работе системы в целом: цели и атрибуты качества, ограничения.

Управление требованиями пользователей при разработке СЭД: собираем, анализируем, используем

Рис. 1. Виды требований

При сборе и формулировании требований к системе необходимо соблюдать основные критерии их  качества:

  • Понятность (недвусмысленность) — требование должно быть понятно сформулировано (исключать неоднозначное толкование).

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

  • Завершенность — требование полностью определено в одном месте и вся необходимая информация присутствует.
  • Атомарность (неделимость) — требование нельзя разделить на более мелкие без потери завершенности.
  •  Единичность  — требование описывает одну и только одну вещь.
  • Уникальность  — каждое требование должно однозначно идентифицироваться (должен использоваться уникальный идентификатор требования).
  • Полнота  —  требование должно быть определено для всех возможных ситуаций.
  • Непротиворечивость (последовательность) — требование не противоречит другим требованиям и документации в целом.
  • Достаточность  детализации — необходимо соблюдать достаточную степень детализации для того чтобы была возможность завершить реализацию требования.
  • Прослеживаемость — требование соответствует деловым нуждам как заявлено заинтересованными лицами и задокументировано.
  • Проверяемость — реализация требования может быть проверена (протестирована).

Источники требований

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

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

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

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

Таким образом, источниками требований являются:

  • руководство (или владелец продукта);
  • владельцы процессов;
  • ключевые пользователи;
  • документы.

Кто принимает требования

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

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

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

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

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

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

Инструменты для управления требованиями

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

Можно, например, использовать для сбора требований файл, созданный в MS Exel  или MS Word. Выглядеть это будет примерно вот так:

Управление требованиями пользователей при разработке СЭД: собираем, анализируем, используем

Рис. 2. Список поступивших запросов

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

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

Каждый запрос должен заводиться как отдельный объект. Тогда можно формировать по заданным правилам отбора представления требований (фильтры), что позволит делать анализ.

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

Кроме того, должна быть возможность связывания требований между собой.

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

Источником требования может быть документ.  В этом случае удобно хранить документ целиком, но отображать в виде отдельных требований критичные для будущего функционала СЭД части документа.

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

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

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

Однако максимально удобное управление требованиями обеспечивают специализированные системы, предназначенные для управления требованиями: например, специальные программные продукты для управления требованиями компании IBM - Requisite Pro или более функциональный  Rational DOORS.

Также для управления требованиями можно использовать такие продукты как HP Requirements Management, RequirementsWin, BorlandCaliber RM, SybasePowerDesigner, и другие.

Ниже на рисунке показан пример представления данных в специализированном инструменте для управления требованиями.

Управление требованиями пользователей при разработке СЭД: собираем, анализируем, используем

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

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

СЛОВАРЬ

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

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

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

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

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

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

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

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

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

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

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

Формализация требований

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

С одним пользовательским запросом может быть связано несколько требований. А иногда требование  определяется на основании сразу нескольких запросов. Все эти связи так же необходимо отображать в атрибутах запросов и требований.

Изменение требований. Корректировка целей

Требования могут меняться на протяжении всего проекта реализации системы (особенно в случае использования методологии SCRUM). Правильнее сказать, они не могут не меняться по ряду объективных факторов и субъективных причин.

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

И не всегда то, что пользователи ожидали увидеть, совпадет с тем, что создали по их требованиям.

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

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

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

Изменение требований естественный процесс и связано это с рядом причин.

Субъективные причины изменения требований могут быть такие как:

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

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

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

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

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

  • Незнанием руководством конкретики внутренних процессов, которые они планируют автоматизировать.

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

  • Неготовность потенциальных пользователей к автоматизации или изменению процессов.

Справиться с этой проблемой помогает обучение.

Объективные причины заключаются в том, что:

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

Это нормально, так как любая компания развивается, может расти и менять свою структуру и бизнес-процессы.

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

Итак, требования поступают как на этапе пресейла, так и на всем протяжении проекта разработки СЭД, а так же ее эксплуатации.

Хотим мы этого или нет, но управление требованиями является непрерывным процессом на протяжении всего жизненного цикла системы.

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

Верификация изменений требований

Для минимизации рисков проекта все изменения требований должны проходить верификацию (позднелат. verificatio — доказательство, подтверждение, от лат. verus — истинный и facio — делаю), так как влияют на функции системы, которые уже были в утвержденной ответственными лицами документации.

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

В случае работы по SCRUM ответственность за верификацию (отбор требований) берет на себя владелец продукта (product owner).

Документирование требований

Требования к системе служат основой для следующих видов документов, разрабатываемых в соответствии с российскими стандартами:

  • Техническое задание

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

  • Технический проект

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

Если обратиться к западным стандартам, то обычно требования используются при разработке таких документов как:

  • Спецификация требований (Requirements Specification)

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

  • Use Case Model (Модели прецедентов (Вариантов использования))

Это комплексная графическая модель вариантов использования с описанием.

  • User Story  (Пользовательская история)

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

  • Концепция (Вижен -Vision)

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

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

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

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

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

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

О. А. Галкина, ведущий аналитик департамента разработки тиражных программных продуктов «БОСС-Референт» компании «Логика бизнеса 2.0»

Анонсы будущих номеров
    Подробнее о журнале


    Ваша персональная подборка

      Подписка на статьи

      Чтобы не пропустить ни одной важной или интересной статьи, подпишитесь на рассылку. Это бесплатно.

      Рекомендации по теме

      Мероприятия

      Мероприятия

      Проверь свои знания и приобрети новые

      Посмотреть

      Самое выгодное предложение

      Самое выгодное предложение

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

      Живое общение с редакцией
      Вебинар «Секретарь в соцсетях. Правила поведения»
      Журнал «Справочник секретаря и офис-менеджера»




      Вопрос - ответ

      Отвечаем на Ваши вопросы

      Какие реквизиты используются при оформлении приказов по основной деятельности?
      Проекты приказов по основной деятельности готовятся по поручению руководителя организации в структурных подразделениях организации, оформляются на специальном бланке и содержат следующие реквизиты
      Недавно устроилась секретарем в компанию, где передо мной встала задача наладить документооборот
      Подскажите, как правильно начать формировать локальную нормативную базу и какие нормативные документы мне в этом помогут? Читайте ответ на вопрос
      Задайте свой вопрос здесь>>> www.sekretariat.ru/pk

      PRO Делопроизводство
      Портал для руководителей служб ДОУ и секретарей всех уровней

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

      Зарегистрировано Федеральной службой по надзору в сфере связи, информационных технологий и массовых коммуникаций (Роскомнадзор). Свидетельство о регистрации ПИ № ФС77-64197 от 25.12.2015


      E-mail: document@sekretariat.ru

      
      • Мы в соцсетях
      Сайт использует файлы cookie. Они позволяют узнавать вас и получать информацию о вашем пользовательском опыте. Это нужно, чтобы улучшать сайт. Если согласны, продолжайте пользоваться сайтом. Если нет – установите специальные настройки в браузере или обратитесь в техподдержку.
      Зарегистрируйтесь и продолжите чтение!

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

      После регистрации вы сможете:

      • читать любые статьи по Делопроизводству и Документообороту на нашем сайте
      • бесплатно подписаться на ежедневные новости для секретарей и офис-менеджеров
      • участие в онлайн вебинарах и возможность задавать вопросы экспертам

      У меня есть пароль
      напомнить
      Пароль отправлен на почту
      Ввести
      Я тут впервые
      И получить доступ на сайт Займет минуту!
      Введите эл. почту или логин
      Неверный логин или пароль
      Неверный пароль
      Введите пароль
      Всего один шаг - и документ Ваш!

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

      У меня есть пароль
      напомнить
      Пароль отправлен на почту
      Ввести
      Я тут впервые
      И получить доступ на сайт Займет минуту!
      Введите эл. почту или логин
      Неверный логин или пароль
      Неверный пароль
      Введите пароль