Конструктор регламентов для сотрудников

Обновлено: 30.04.2024

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

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

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

Документ, содержащий регламент процесса, формируется в карточке процесса на вкладке Регламент (рис. 1).

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

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

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

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

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

Так, в любом регламенте деятельности должна содержаться следующая информация:

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

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

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

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

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

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

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

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

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

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

Внедрение системы внутренней нормативной документации может осуществляться как с использованием информационных систем, так и без. В качестве основы для внедрения системы стандартов может выступать как единая система (например, конфигурации 1С: Предприятие), так и системы электронного документооборота и класса workflow. Преимуществом использования средств автоматизации является то, что поддерживается единая методология, зачастую «зашитая» в сам продукт (например, Aris, Corporate Modeler). Кроме того, при использовании информационных систем упрощается отслеживание версий документов, прав доступа к ним, а также действий пользователей, если эти действия регистрируются системой.

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

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

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

Регламент разработки и внедрения программных продуктов

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

1.1. Настоящий регламент имеет целью определить правила организации и проведения работ по разработке и внедрению собственных программных продуктов в ОАО «ХХХ» (далее – Предприятие).

1.2. Основными задачами настоящего регламента в рамках регулирования деятельности по разработке и внедрению программных продуктов являются:

– определение сферы применения;

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

– определение требований к процедурам деятельности;

– разграничение прав и обязанностей участников деятельности;

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

1.3.1. АИС – Информационная система, созданная для решения задач автоматизации деятельности и бизнес-процессов Предприятия, в рамках которой осуществляется внедрение Программного продукта.

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

1.3.3. Проект – задача на разработку и внедрение Программного продукта, регулируемая Техническим заданием.

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

– служебные записки – основания разработки (изменения) Проекта;

– план внедрения Проекта;

– протоколы тестирования Программного продукта;

– акт внедрения Программного продукта;

– иные документы, регулирующие процесс внедрения конкретного проекта.

1.3.5. Техническое задание – основной документ Проекта, содержащий описание задачи, цель и способы ее внедрения, а также требования к Программному продукту и АИС.

1.4. Деятельность Предприятия по разработке и внедрению программных продуктов регулируется:

– утвержденными Техническими заданиями;

– другими нормативными документами Предприятия.

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

– лица, заинтересованные в создании (изменении) функционала АИС;

– руководитель деятельности по разработке и внедрению программных продуктов;

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

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

1.5.3. Администратор АИС – лицо, ответственное за функционирование действующей АИС. Администратор АИС единолично несет ответственность за АИС и в рамках настоящего регламента выполняет следующие задачи:

– при необходимости обеспечивает руководителя проекта и исполнителей работ копиями АИС для разработки Программного продукта;

– интегрирует готовый Программный продукт в АИС.

1.6. Разработка и внедрение программных продуктов включает следующие процедуры:

1) постановка задачи и запуск Проекта;

2) написание и утверждение Технического задания;

3) выполнение работ по проектированию Программного продукта;

4) окончательное тестирование и приемка Программного продукта;

5) внедрение Программного продукта в АИС.

2. Постановка задачи и запуск проекта

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

– АИС, которую необходимо создать (модифицировать);

– деятельность (процессы), подлежащие автоматизации;

– требования к функционалу АИС;

– срочность реализации с указанием обоснования реализации Проекта в срочном порядке;

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

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

2.2. Сферой действия настоящего регламента является автоматизация следующих задач:

– проекты на разработку и внедрение новых АИС;

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

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

2.3. Основаниями для признания существенными изменений (дополнений) функционала действующих АИС являются следующие условия:

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

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

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

2.5. Если Проект не попадает в сферу применения настоящего регламента, то принятие решений о реализации Проекта настоящим регламентом не регулируется.

2.6. План внедрения проекта должен содержать, как минимум, следующую информацию:

– ответственных за выполнение работ;

– при необходимости исполнителей работ;

– оценки объема работ в часах;

– нормативные сроки завершения работ.

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

2.7. Руководитель проекта выполняет следующие функции:

– анализ возможностей и способов внедрения Проекта;

– организация процессов, необходимых для внедрения Проекта;

– координация действий участников внедрения Проекта;

– проведение консультаций с участниками внедрения для решения спорных вопросов;

– назначение исполнителей работ по Проекту;

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

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

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

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

3.3. Техническое задание должно содержать в себе, как минимум, следующую информацию:

– наименование и краткую характеристику АИС;

– назначение и функции предмета разработки;

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

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

– требования к информационной и программной совместимости;

– требования к защите информации отдельно для АИС и предмета разработки;

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

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

– особые требования к проведению приемки работ (по необходимости);

– условия взаимодействия с другими проектами (по необходимости);

– другая необходимая информация.

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

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

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

– перечень автоматизируемых операций;

– создаваемые (модифицируемые) объекты АИС, их состав и правила функционирования;

– методология автоматизации для каждой операции и создаваемого (модифицируемого) объекта АИС;

– принципы организации работы пользователей в АИС, связанные с внедрением Программного продукта.

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

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

– виды планируемых пользовательских инструкций (руководств);

– планирование встроенной справки для объектов АИС, создаваемых (модифицируемых) предметом разработки (Программным продуктом);

– планирование встроенной справки к АИС в целом.

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

– поддерживаемые форматы загрузки и выгрузки данных (требования к выгружаемым и загружаемым файлам);

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

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

3.10. Требования к защите информации включают следующее:

– правила ограничения доступа к данным для пользователей АИС;

– использование средств криптографической защиты;

– использование защищенных каналов связи для АИС и др.

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

3.12. Техническое задание подписывают следующие лица:

– разработчик технического задания (автор);

– руководитель проекта (требуется согласование, если руководитель проекта не является разработчиком технического задания);

– исполнитель (требуется ознакомление, если исполнитель не является руководителем проекта или разработчиком технического задания);

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

4. Порядок выполнения работ и внедрения программных продуктов

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

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

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

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

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

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

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

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

– описание предмета разработки (Программного продукта) и всех его объектов;

– инструкции (руководства) пользователей АИС по эксплуатации предмета разработки (Программного продукта);

– историю изменений Программного продукта от версии к версии.

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

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

4.5. Тестирование, предшествующее приемке Программного продукта, проводит руководитель проекта, который проверяет:

– выполнение требований технических заданий;

– соблюдение общих принципов и требований к разработке, вытекающих из настоящего регламента;

– отсутствие ошибок в работе Программного продукта.

4.6. По итогам проведения тестирования руководитель проекта принимает одно из следующих решений:

– Программный продукт соответствует предъявляемым требованиям и готов к внедрению в АИС (в этом случае следующей процедурой является приемка Программного продукта);

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

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

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

– заключение о соответствии Программного продукта предъявляемым требованиям;

– наличие необходимости в доработке Программного продукта;

– перечень необходимых исправлений с указанием нарушенных требований (при наличии нарушений);

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

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

4.9. В приемную комиссию могут включаться следующие лица:

– руководитель деятельности по разработке и внедрению программных продуктов;

– лица, заинтересованные во внедрении Программного продукта;

– представители руководства Предприятия.

Руководитель проекта и исполнители работ по проекту в состав приемной комиссии включаться не могут.

4.10. Приемная комиссия определяет пригодность Программного продукта для внедрения в АИС и соответствие функционала Программного продукта предъявляемым требованиям. По результатам приемки приемная комиссия принимает одно из следующих решений:

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

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

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

4.12. Интеграция Программного продукта в работающую АИС до завершения процедуры приемки и составления акта внедрения не допускается. По окончании процедуры приемки внедрение Программного продукта в АИС осуществляет администратор АИС.

4.13. Документация проекта сшивается и сдается на ответственное хранение в отдел информационных технологий аппарата управления Предприятия. Хранение документации проекта осуществляется до завершения использования Программного продукта в деятельности Предприятия.

Целью проекта является разработка, систематизация, переработка и актуализация регламентирующей документации при помощи Business Studio, формирование web- справочника знаний о деятельности организации.

Задачи проекта

Формирование каталога нормативных, методических, организационных, распорядительных, управленческих и справочных документов;
Разработка справочника терминов и сокращений;
Разработка регламентов бизнес-процессов с детализацией на 1–3 уровня в выбранных Заказчиком графических нотациях моделирования (IDEF0, CFFC, EPC, BPMN, BFC);
Формирование модели организационной структуры, разработка (актуализация) положений о подразделениях, должностных и ролевых инструкций;
Разработка справочников информационных систем, баз данных;
Разработка ключевых показателей результативности и эффективности;
Разработка реестра рисков, определение причин и последствий рисковых событий, формирование мероприятий по управлению рисками;
Разработка справочников ТМЦ, информации, подсистем управления, проектов и др;
Разработка шаблонов регламентирующих документов;
Разработка дополнительных справочников под потребности Заказчика;
Разработка правил актуализации документов и информации в web-справочнике;
Формирование web-справочника знаний о деятельности организации с системой поиска и актуализации информации;
Обучение специалистов Заказчика работе в Business Studio, формированию регламентирующей документации.

Результаты проекта

По итогам выполнения проекта Заказчик получит:

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

Глобальные настройки регламента процесса создаются в Дизайнере ELMA через Меню в подразделе Регламент процессов раздела Настройки (рис. 1).

Шаблоны регламентов

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

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

В базовую поставку системы входит "Системный шаблон", сформированный в соответствии с рекомендациями, изложенными в книге "Виталий Елиферов, Владимир Репин. Бизнес-процессы. Регламентация и управление".

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

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

Добавление шаблона регламента

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

– выбрать файл с шаблоном. Откроется окно проводника файлов операционной системы вашего компьютера.

– открыть файл шаблона в редакторе MS Word, если он установлен в операционной системе.

Читайте также: