Одним из важных этапов на проекте внедрения 1С является обучение сотрудников новой программе. Этап становится довольно «болезненным», если заказчик не согласен на обучение. Тогда рассматривается альтернативный вариант – написать руководства пользователей.
В этой статье я поделюсь опытом написания инструкций на проекте внедрения 1С. Расскажу, как писать ПОНЯТНЫЕ руководства пользователей, и главное – как внедрить в компании регламент для сотрудников.
Руководство пользователя – это технический документ, который предназначен для оказания поддержки пользователям конкретной системы. В этом смысле используется и слово «мануал» (manual).
Рассмотрим основной алгоритм написания инструкций для пользователей программы 1С.
1. ОПРЕДЕЛЯЕМ ТЕМУ И ЦЕЛЕВУЮ АУДИТОРИЮ
Для чего мы пишем инструкцию? Самый важный вопрос, на который нужно ответить. Я выделила несколько основных вариантов:
-
Инструкция для конкретного блока учета в программе, например, «Инструкция по блоку Продажи»,
-
Инструкция для определенной должности сотрудника, например, «Инструкция для менеджера по оптовым продажам»,
-
Инструкция по конкретной функции или процессу, например, «Инструкция по маркировке товаров».
Для кого мы пишем инструкцию? Необходимо понять для какого уровня пользователя нужно описать функционал программы – это новичок или опытный пользователь?
Эти вопросы стоит обсудить с заказчиком, ведь от них зависит основной принцип разработки инструкций.
2. ПРОДУМЫВАЕМ СТРУКТУРУ СОДЕРЖАНИЯ
Для выстраивания взаимосвязи разделов важно знать и понимать набор процессов и последовательность их действий. Разобраться в этом помогут:
-
Концептуальный дизайн – основа для дальнейшей разработки проектных решений. Документ включает в себя модели бизнес-процессов, подлежащих автоматизации, проектирование ролей и полномочий, интеграционную модель, альбомы печатных и отчетных форм.
-
Проектное решение – это документ, состоящий из методологического проектного решения, которое фиксирует функциональный объем проекта – определяет какие действия и сущности будут «покрыты» функционалом информационной системы, а также технического проектного решения, которое фиксирует объем, принципы и описание доработок конфигурации 1С и является основой для дальнейшей доработки – изменения типовых и создания новых объектов конфигурации 1С.
-
Встречи с заказчиком.
Инструкция по блоку. Заголовок раздела – объект программы.
Пример: блок учета – ценообразование, процессы – ведение информации о видах цен, сегментах партнеров, установка цен номенклатуры, использование обработок. Тогда структура содержания может выглядеть следующим образом:
Инструкция для должности. Заголовок раздела – название процесса.
Пример: пользователь – кладовщик ордерного склада, функции и их последовательность – приемка и отгрузка товаров, учет товарно-материальных ценностей в эксплуатации. Тогда структура содержания может выглядеть следующим образом:
Инструкция по процессу. Заголовок раздела – название процесса, объекта программы, должности.
Пример: процесс – реализация маркированных товаров. Менеджер по продажам создает реализацию товаров, выгружает данные на терминал сбора данных, затем кладовщик на складе считывает товары на терминал сбора данных и заносит их в 1С. Тогда структура содержания может выглядеть следующим образом:
3. ПИШЕМ ИНСТРУКЦИЮ
Перед аналитиком встала ответственная задача – написать инструкцию так, чтобы тебя поняли. Рассмотрим основные принципы написания мануалов.
Содержательность. Опишите функционал программы, расскажите в деталях обо всех этапах, нюансах и распространённых ошибках.
Подробная или не очень
Если инструкцией будет пользоваться новичок, то я рекомендую сделать следующее: поставьте себя на место пользователя, который первый раз в жизни видит программу. Такая инструкция будет очень подробная.
Если пользователь ранее работал в подобных программах, например, менеджер по продажам имеет опыт работы с программой 1С: Управление торговлей 11, тогда ему будет не сложно заполнить нормативно-справочную информацию и создать документы «Заказ клиента» и «Реализация товаров и услуг». Такая инструкция будет содержать меньше конкретики.
Полнота изложения
Не сокращайте слова, не используйте аббревиатуры и специальные термины, понятные только узкому кругу читателей. Текст должен быть понятен любому. Например, вместо «РТиУ» не поленитесь и пропишите полностью «документ Реализация товаров и услуг». Если без этого никак — оформите раздел «Глоссарий».
Ветвления
Если процессы повторяются или нужно сослаться на другой раздел, то необходимо проставить гиперссылки. Например: «Базовые соглашения с клиентом не используются в документах продаж, для этого необходимо создать индивидуальное соглашение».
Если вы ссылаетесь на рисунок или таблицу, то воспользуйтесь механизмом «Перекрестная ссылка».
Структурированность.
Разбавьте текст заголовками, абзацами и списками для удобного восприятия читателем.
Заголовки – это обязательно.
Позволяют «просканировать» ваш текст и остановиться сразу на нужной части. Но главное – не нарушать их иерархию.
Абзацы – это не так просто.
Есть универсальное правило: одна мысль – один абзац. Он не должен быть огромным, чтобы не перегружать информацией. Но и делать абзац из одного предложения тоже не стоит. Оптимальная длина – 5 строк.
Списки – это удобно и понятно.
Маркированный список – это обычный список перечисления с маркерами, точками. В перечне элементы не упорядочены между собой. От их перестановки местами смысл не поменяется.
Нумерованный список уместно использовать, если вы перечисляете этапы чего-то. Если элементы поменять местами, нарушится смысл.
Пример: чтобы оформить приобретение товаров через подотчётное лицо, необходимо выполнить следующие действия:
1) Перейдите в раздел Закупки – Документы закупки (все).
2) Нажмите кнопку «Создать – Приобретение товаров и услуг – Закупка через подотчетное лицо».
3) Укажите на вкладке «Основное» следующие данные:
-
Организация,
-
Поставщик,
-
Контрагент,
-
Договор,
-
Склад.
4) Заполните вкладку «Товары».
5) Укажите на вкладке «Доставка» способ доставки.
6) Нажмите кнопку «Провести и закрыть».
Наглядность. Японское правило: «Одна картинка стоит тысячу слов».
Скриншоты
Текст разбавляем скриншотами. Их желательно делать в той программе или интерфейсе, который есть у всех сотрудников, как правило – это тестовая рабочая база. Возможно редактирование скриншотов стрелками, выделением цветом нужных элементов и порядка действий. Таким образом, пользователю будет проще понять, что необходимо сделать.
Подпишитесь на дайджест!
Подпишитесь на дайджест, и получайте ежемесячно подборку полезных статей.
Пример: чтобы установить значение цены номенклатуры в документе «Установка цен номенклатуры», необходимо выбрать подразделение, все влияющие и зависимые виды цен, затем перейти к установке:
Делюсь удобными и бесплатными инструментами для создания скриншотов:
-
Lightshot. Скачать можно тут.
-
Яндекс.Скриншот, входит в состав утилиты Яндекс.Диск. Посмотреть можно тут.
Важные фрагменты текста
Если читателю обязательно нужно обратить внимание на важный фрагмент текста, то перед описанием можно указать слова «Важно», «Обратите внимание» и сделать акцент на размер, шрифт и цвет текста.
Пример: Обратите внимание!!! Обычный менеджер не сможет отредактировать график оплаты в соглашении c клиентом. Для этого предусмотрена отдельная роль. Если данный функционал не доступен, то необходимо обратиться в ИТ-отдел.
Экспертность. Автор обязан хорошо разбираться в теме.
Если так вышло, что описываемый блок программы – новая тема для аналитика, тогда за основу типового функционала рекомендую взять инструкции с официального сайта 1С: ИТС.
Можно указать в тексте интерактивные ссылки на инструкции с сайта, чтобы не перегружать документ. Но если у пользователей нет выхода к интернету, то этот вариант не подходит.
Актуальность.
Инструкцию придется периодически обновлять.
Если порядок действий, интерфейс программы, который вы описываете, меняется, то инструкцию нужно обновлять. Вопрос – кто должен это делать?
- Если изменение произошло во время написания инструкции, например, обновилась версия программы или был доработан функционал, тогда сделать это нужно автору мануала в оперативном режиме.
- Если инструкции приняты заказчиком или проект уже закончен, в этом случае за актуальность отвечает заказчик.
4. ПРОВЕРЯЕМ, ПРОВЕРЯЕМ И ЕЩЕ РАЗ ПРОВЕРЯЕМ
Чтобы написать грамотную пошаговую инструкцию, вы сами напрямую должны были с этим столкнуться и прийти к успешному результату. Поэтому, как только вы закончили – сядьте и проделайте последовательно все действия из документации. Лучше тестируйте под правами пользователя, так как это поможет выявить недочеты и устранить ошибки не только в тексте, но и в доработанном функционале.
Итак, мы написали руководство пользователя, проверили его и сдали заказчику. Следующий этап – внедрение инструкции для сотрудников на предприятии.
КАК ВНЕДРИТЬ ИНСТРУКЦИИ ДЛЯ СОТРУДНИКОВ
Ответственность за внедрение инструкций полностью лежит на стороне заказчика. Как добиться, чтобы сотрудники читали инструкции и выполняли предписания? Если в компании нет службы или сотрудника, который контролирует соблюдение регламентов, они не будут выполняться. Возможно, руководитель сумеете вдохновить сотрудников в самом начале, они будут действовать по инструкции, но после перестанут ими пользоваться.
Правило №1. Должностные папки
Что нужно сделать, чтобы инструкции работали? Для начала убедитесь, что они появились в должностных папках сотрудников. Эти папки могут быть как физическими, так и электронными.
Правило №2. Проверка знаний
Скорее всего сотрудники никогда не будут читать и разбираться в инструкциях, если вы не будете проверять знания. Единственный способ мотивировать их — предупредить, что служба ИТ-отдела проведет тестирование понимания мануала. Тогда необходимость прочесть регламент и разобраться в нем станет для сотрудников очевидной.
Правило №3. Контроль выполнения
Служба ИТ-отдела должна проверять, как на самом деле выполняются регламенты в компании. Понятно, что мы не можем тратить на это много времени и ресурсов. Здесь нужно здравомыслие: просто устраивайте проверки с определенной периодичностью.
ПОДЫТОЖИМ. Для того, чтобы написать качественную инструкцию нам нужно:
1. Определить тему и целевую аудиторию.
2. Продумать структуру содержания.
3. Написать инструкцию, соблюдая следующие критерии:
-
Содержательность,
-
Структурированность,
-
Наглядность,
-
Экспертность,
-
Актуальность.
4. Проверить инструкцию под правами пользователя.
Чтобы правильно внедрить регламент, необходимо соблюдать три правила:
1. Регламент попал к сотрудникам, и вы в этом убедились.
2. Сотрудник его прочитал, понял и прошел проверку знаний.
3. Соблюдение регламента контролируется.
Техническая документация является составляющей проекта по созданию, внедрению, сопровождению, модернизации и ликвидации информационной системы на всем протяжении жизненного цикла.
Комплекс технических документов, который регламентирует деятельность разработчиков, называется нормативно-методическим обеспечением (НМО). В данный комплекс входят:
ü стандарты;
ü руководящие документы;
ü методики и положения;
ü инструкции и т. д.
НМО регламентирует порядок разработки, общие требования к составу и качеству программного обеспечения (ПО), связям между компонентами, определяет содержание проектной и программной документации.
Основным назначением технической документации является обеспечение эффективных процедур разработки и использования информационной системы как программного продукта, а также организация обмена между разработчиками и пользователями ИС.
Таким образом, можно выделить следующие функции технической документации:
ü дает описание возможностей системы;
ü обеспечивает фиксацию принятых и реализованных проектных решений;
ü определяет условия функционирования ИС;
ü предоставляет информацию об эксплуатации и обслуживании ИС;
ü регламентирует процедуру защиты информации, регулирует права различных групп пользователей;
ü определяет возможности модернизации системы.
Перед составлением технической документации необходимо иметь ответы на следующие вопросы:
ü что и зачем должно быть документировано?
ü для кого предназначен тот или иной документ?
ü какие ошибки может допустить пользователь и что нужно сделать для их устранения?
ü как и в каких условиях будет использоваться документ?
ü каковы сроки разработки документа?
ü как будет обновляться и поддерживаться документация, каковы механизмы и сроки внесения изменений и пересмотра документов и кто ответственен за реализацию этих действий, а также за хранение, неизменность и контроль за исполнением?
ü кто будет оценивать документ и как он соотносится с отраслевыми или ведомственными требованиями на сертификацию разработки?
Ответы на эти вопросы должны быть получены на ранних стадиях разработки информационной системы и входить в состав разрабатываемой в рамках проекта документации.
Как правило, к технической документации предъявляются следующие основные требования:
ü документы должны быть точными, полными и, по возможности, краткими, иметь четкое и однозначное толкование;
ü документация должна создаваться параллельно с разработкой самой информационной системы;
ü обязанности по документированию системы лежат на ее разработчике;
ü для повышения эффективности работы с документами должны использоваться стандарты, регламентирующие форму и содержание документов.
Исходя из последнего требования к документации, необходимо рассмотреть основные стандарты, которые используются в области информационных систем на территории Российской Федерации.
В настоящее время существует несколько классификаций стандартов на проектирование и разработку информационных (автоматизированных) систем. Классический способ классификации группирует стандарты по двум признакам.
По объекту стандартизации:
ü стандарты на продукты и услуги;
ü стандарты на процессы и технологии.
По предмету стандартизации:
ü функциональные стандарты (стандарты на языки программирования, протоколы, интерфейсы);
ü стандарты на организацию жизненного цикла (ЖЦ) автоматизированных систем и программного обеспечения.
Альтернативная классификация группирует стандарты по статусу:
ü официальные стандарты;
ü стандарты «де-факто».
В свою очередь официальные стандарты подразделяются на:
þ международные стандарты (ISO, ANSI, IDEF0/1);
þ стандарты Российской Федерации (ГОСТ);
þ отраслевые стандарты;
þ ведомственные стандарты.
Стандартами «де-факто» являются официально никем не утвержденные, но фактически действующие стандарты.
Как правило, в каждую из этих групп входят документы, существенно разные по степени обязательности для организаций, конкретности и детализации содержащихся требований, открытости и гибкости, а также адаптируемости к конкретным условиям.
Отдельно выделяют корпоративные стандарты.
Для большинства сложных проектов приходится создавать свои комплексы нормативных и методических документов, регламентирующих процессы, этапы, работы и документы конкретных программных продуктов. Такие стандарты называют корпоративными и представляют собой соглашение о единых правилах организации технологии или управления в организации. К таким стандартам относятся:
ü стандарты проектирования;
ü стандарты оформления проектной документации;
ü стандарты пользовательского интерфейса.
Стандарт проектирования должен устанавливать:
þ набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;
þ правила именования объектов, оформления диаграмм, включая требования к форме и размерам объектов и т. д.
þ требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы;
þ правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии, правила проверки проектных решений на непротиворечивость.
Стандарт оформления проектной документации должен устанавливать:
þ комплектность, состав и структуру документации на каждой стадии проектирования;
þ требования к ее оформлению, включая требования к содержанию разделов, подразделов, пунктов, таблиц и т. д.
þ правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии;
þ требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации;
þ требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.
Стандарт интерфейса пользователя должен устанавливать:
þ правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;
þ правила использования клавиатуры и мыши;
þ правила оформления текстов помощи;
þ перечень стандартных сообщений;
þ правила обработки реакции пользователя.
За основу корпоративных стандартов могут приниматься отраслевые, национальные или международные стандарты. Сюда могут относиться различные методические материалы ведущих фирм-разработчиков ПО, научных центов, фирм-консультантов, консорциумов по стандартизации.
Отечественными стандартами являются стандарты ЕСПД (Единой Системы Программной Документации) серии ГОСТ 19.ХХХ и комплекс стандартов на автоматизированные системы серии ГОСТ 34.ХХХ, созданные в 80-90-е годы двадцатого века. Кроме того, существуют более современные стандарты на программное обеспечение.
Перечень стандартов ГОСТ 19.ХХХ
Единая Система Программной Документации
ü ГОСТ 19.001-77 Общие положения
ü ГОСТ 19.101-77 Виды программ и программных документов
ü ГОСТ 19.102-77 Стадии разработки
ü ГОСТ 19.103-77 Обозначения программ и программных документов
ü ГОСТ 19.104-78 Основные надписи
ü ГОСТ 19.105-78 Общие требования к программным документам
ü ГОСТ 19.106-78 Требования к программным документам, выполненным печатным способом
ü ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению
ü ГОСТ 19.202-78 Спецификация. Требования к содержанию и оформлению
ü ГОСТ 19.301-79 Программа и методика испытаний. Требования к содержанию и оформлению
ü ГОСТ 19.401-78 Текст программы. Требования к содержанию и оформлению
ü ГОСТ 19.402-78 Описание программы
ü ГОСТ 19.403-79 Ведомость держателей подлинников
ü ГОСТ 19.404-79 Пояснительная записка. Требования к содержанию и оформлению
ü ГОСТ 19.501-78 Формуляр. Требования к содержанию и оформлению
ü ГОСТ 19.502-78 Описание применения. Требования к содержанию и оформлению
ü ГОСТ 19.503-79 Руководство системного программиста. Требования к содержанию и оформлению
ü ГОСТ 19.504-79 Руководство программиста. Требования к содержанию и оформлению
ü ГОСТ 19.505-79 Руководство оператора. Требования к содержанию и оформлению
ü ГОСТ 19.506-79 Описание языка. Требования к содержанию и оформлению
ü ГОСТ 19.507-79 Ведомость эксплуатационных документов
ü ГОСТ 19.508-79 Руководство по техническом обслуживанию. Требования к содержанию и оформлению
ü ГОСТ 19.601-78 Общие правила дублирования, учета и хранения
ü ГОСТ 19.602-78 Правила дублирования, учета и хранения программных документов, выполненных печатным способом
ü ГОСТ 19.603-78 Общие правила внесения изменений
ü ГОСТ 19.604-78 Правила внесения изменений в программные документы, выполненных печатным способом
Стандарты ЕСПД практически не имеют содержательной составляющей и дают формальные требования к составу, содержанию и оформлению документов, описывающих программу на разных стадиях ее жизненного цикла.
Комплекс ГОСТ 34 задумывался как всеобъемлющий комплекс взаимоувязанных межотраслевых документов и рассчитанный на взаимодействие заказчика и разработчика. Он должен был разрешить проблему «вавилонской башни», при которой в различных отраслях и областях деятельности использовалась плохо согласованная или несогласованная нормативно-техническая документация. Объектами стандартизации являются автоматизированные системы различных видов и все виды их компонентов, а не только программное обеспечение и базы данных. Комплекс рассчитан на взаимодействие заказчика и разработчика, при этом в нем предусмотрено, что заказчик может разрабатывать систему для себя сам.
Перечень стандартов ГОСТ 34.ХХХ
Стандарты информационной технологии
ü ГОСТ 34.003-90 Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения
ü ГОСТ 34.201-89 Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначения документов при создании автоматизированных систем
ü ГОСТ 34.320-96 Информационные технологии (ИТ). Система стандартов по базам данных. Концепции и терминология для концептуальной схемы и информационной базы
ü ГОСТ 34.321-96 Информационные технологии (ИТ). Система стандартов по базам данных. Эталонная модель управления данными
ü ГОСТ 34.601-90 Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания
ü ГОСТ 34.602-89 Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы
ü ГОСТ 34.603-92 Информационная технология (ИТ). Виды испытаний автоматизированных систем
ü РД 50-34.698-90 Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов
Многие авторы считают эти стандарты морально устаревшими, однако ими продолжают активно пользоваться при оформлении проектной документации. Если разрабатывается документация на программу (систему), созданную под конкретную организацию, следует воспользоваться требованиями ГОСТов 34. Если разрабатывается документация на программу массового применения, то следует использовать ГОСТы серии 19.
Если говорить о более поздних отечественных стандартах, следует выделить ГОСТ Р 51904-2002 Программное обеспечение встроенных систем. Общие требования к разработке и документированию, который был разработан Государственным научно-исследовательским институтом авиационных систем с участием Научно-исследовательского института стандартизации и унификации. Данный стандарт распространяется на процессы разработки и документирования программного обеспечения встроенных систем реального времени и все действия, имеющие отношение к разработке программного обеспечения. Стандарт подготовлен в развитие ГОСТ Р ИСО/МЭК 12207 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств, о котором пойдет речь в п. 2.3.
Отдельно стандарт ГОСТ Р 51904-2002 в части подготовки документов будет рассмотрен в главе 9 «Программное обеспечение».
Международные стандарты применяются для разработки документации международного уровня. Как правило, они не бесплатные, так как разрабатываются не государственными организациями, но, в отличие от отечественных, разработаны недавно.
В основе практически всех современных промышленных технологий создания программных средств лежит международный стандарт ISO/IEC 12207 Information technology. System and software engineering. Software life cycle processes (ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств). Первая редакция стандарта ISO/IEC 12207 была опубликована в августе 1995 г. и явилась первым международным стандартом, содержавшим представительный набор процессов жизненного цикла в отношении программного обеспечения, которое рассматривалось как часть большой системы, а также применительно к программным продуктам и услугам. Стандарт определяет процессы, виды деятельности и задачи, которые используются при приобретении программного продукта или услуги, а также при поставке, разработке, применении по назначению, сопровождении и прекращении применения программных продуктов.
Основными характеристиками данного стандарта являются:
ü динамичность: один процесс при необходимости вызывает другой или его часть, что позволяет реализовать любую модель жизненного цикла;
ü адаптивность: стандарт предусматривает исключение процессов, видов деятельности и задач, неприменимых в конкретном проекте.
Кроме того, существуют международные стандарты (на английском языке), которые направлены на написание документации:
1. IEEE Std 1063-2001 «IEEE Standard for Software User Documentation» – стандарт для написания руководства пользователя. В документе обозначены требования к структуре, содержимому и формату инструкций пользователя.
2. IEEE Std 1016-1998 «IEEE Recommended Practice for Software Design Descriptions» – стандарт для написания технического описания программы. Представлены рекомендации к документам, описывающим архитектуру программного обеспечения.
3. ISO/IEC FDIS 18019:2004 «Guidelines for the design and preparation of user documentation for application software» – стандарт для написания руководства пользователя. В данном документе есть большое количество примеров. Также в приложениях есть чек-листы «что не забыть сделать в процессе разработки документации» и «что должно быть».
Документ особенно полезен начинающим специалистам.
4. ISO/IEC 26514:2008 «Requirements for designers and developers of user documentation» – стандарт для дизайнеров и разработчиков пользователей документации.
Международных стандартов довольно много, в каждой стране они свои, так как один и тот же стандарт не всегда может подойти и европейским, и азиатским компаниям.
Разработка руководства по эксплуатации
При выпуске в обращение технически сложной продукции в состав ее сопроводительной документации должно входить руководство по эксплуатации. Документ содержит основные правила использования, хранения и транспортировки изделия, особенности обслуживания и способы применения, позволяющие максимально продлить срок службы. РЭ также включает подробное описание продукта, в том числе, технические характеристики, параметры, конструкцию, принцип действия, инструкцию по сборке и ремонту в случае поломки.
Для чего разрабатывается РЭ?
Основной целью разработки руководства по эксплуатации является обеспечение безопасной долгосрочной работы оборудования и исключение риска причинения вреда здоровью человека. Без РЭ невозможно пройти процедуру оценки соответствия товара и получить разрешительный документ: сертификат или декларацию.
Такие сертификационные документы необходимы для законного производства и импорта оборудования и устройств.
Требования к содержанию документа
Содержание руководства по эксплуатации регламентировано действующими нормативно-правовыми актами и может незначительно отличаться в зависимости от вида и назначения продукции. Однако, несмотря на это, РЭ включает следующие обязательные разделы:
- полное наименование изделия;
- основные технические характеристики, сведения о конструктивных особенностях, основных свойствах устройства;
- составные элементы, формирующие комплектность изделия;
- принцип работы;
- меры предосторожности и обеспечения безопасной эксплуатации;
- этапы сборки и монтажа;
- указания по регулировке и наладке:
- информация о периодическом сервисном обслуживании и ремонте;
- возможные причины возникновения поломок, ошибок и правила их устранения;
- условия гарантии производителя;
- данные о периоде службы и ресурсе;
- сведения о транспортировке и упаковке;
- порядок вывода из эксплуатации и утилизации;
- данные об испытательных мероприятиях продукции;
- информация о вводе в эксплуатацию.
Дополнительные схемы, рисунки, фотографии, чертежи и таблицы способствуют более правильному восприятию пользователем сложной технической информации.
Нормативные документы
Порядок разработки инструкции по эксплуатации отражен в национальных стандартах:
- ГОСТ 2.601-2013 регулирует требования к содержанию руководства пользователя;
- ГОСТ 2.610-2006 содержит основные правила оформления РЭ.
Документом по составлению РЭ, имеющим международный статус, является технический регламент Таможенного союза. ТР ТС 010/2011, включающий в себя стандарты безопасности машин и оборудования, содержит расширенные требования к оформлению руководства по эксплуатации на технически сложные объекты.
Именно данный регламент предполагает создание РЭ как неотъемлемую часть процесса проектирования изделия. Также требования к разработке РЭ содержаться в других узкоспециализированных нормативно-технических документах международного торгово-экономического альянса (ЕАЭС), например: ТР ТС 032/2013, ТР ТС 016/2011
Правила оформления
Вся информация, изложенная в руководстве по эксплуатации, должна соответствовать требованиям действующих нормативно-технических актов. Содержание РЭ должно быть достаточным для использования как специалистом, так и простым пользователем. Документ должен быть изложен понятно и доступно, чтобы у потребителя не возникало трудностей в процессе эксплуатации продукции. Особенно это касается технически сложных объектов, машин и механизмов, подлежащих обязательной сертификации, — анализ РЭ в этом случае является важным этапом процедуры оценки соответствия.
Также в инструкции по эксплуатации должны быть отражены меры предосторожности и указания по оценке технического состояния изделия для определения необходимости текущего и внепланового ремонта. Специалисты сервисного обслуживания довольно часто используют РЭ в работе, поэтому при его составлении необходимо это учитывать, так как документ должен содержать исчерпывающую информацию, необходимую экспертам.
Согласно требованиям ТР ТС 010, руководство по эксплуатации подобно обоснованию безопасности — документу, который разрабатывается при проектировании. Таким образом, многие разделы РЭ идентичны или тесно переплетаются с положениями ОБ.
Необходимая документация
- заявка на разработку РЭ;
- информация о предприятии, инициирующем разработку инструкции по эксплуатации (наименование, реквизиты, учредительные и регистрационные документы);
- документация на изделие, устройство или оборудование.
Заказать разработку РЭ или ознакомиться с дополнительной информацией можно у сотрудников сертификационного центра «ГОСТ Р». Консультации бесплатны!
Отправьте заявку
Руководство пользователя – это основной документ в составе эксплуатационной документации на автоматизированную систему (ГОСТ 34). Очевидно ли это?
Назначение руководства пользователя
Цель создания документа заключается в том, чтобы предоставить пользователю возможность самостоятельно решать свои прикладные задачи с помощью системы. Этой цели может служить и введение в предметную область, и ознакомление со всеми возможностями программы, и описание конкретных процедур решения задач, и приведение различных инструкций. Иногда Руководство пользователя больше похоже на справочник, к которому можно обращаться в процессе работы, а иногда – на учебник, который позволяет изучить принципы работы с программой и ее возможности, а затем применять их на практике.
Состав типового руководства пользователя
Конкретный подход к написанию определяется многими факторами:
– назначением программы и областью ее применения;
– сложностью программы;
– количеством разнообразных вариантов использования.
Принимая во внимание все различия и особенности, сложно привести структуру любого Руководства пользователя к одному виду. Тем не менее, РД 50-34.698 предлагает нам такой список разделов:
– Введение, где указывают область применения ПО, краткое описывают его возможности, требуемый уровень знаний пользователя и список документов, которые необходимо изучить помимо настоящего руководства;
– Назначение и условия применения, где описывают виды деятельности и функции, которые автоматизированы и условия, при соблюдении которых автоматизация используется;
– Подготовка к работе, где описывают комплектность дистрибутива, порядок установки и загрузки программы, а также способ проверки ее работоспособности;
– Описание операций, представляет собой основной раздел, где описывают функции программы, процессы работы с данными, выполнение конкретных задач пользователя;
– Аварийные ситуации, где описывают действия в нештатных ситуациях – сбоях в программе, ошибок в данных и т.д.;
– Рекомендации по освоению, где приводят методические рекомендации по изучению программы и примеры использования.
Данная структура может меняться и дополняться – например, основной раздел часто разбивают на несколько значимых разделов по группам функций или задач, также в современных системах нередко добавляют раздел Интерфейс пользователя, где описывают взаимодействие пользователя с программой с примерами и снимками экрана.
Стандарты для руководства пользователя
Наличие Руководства пользователя регламентируется ГОСТ 34.201, а структура и содержание – РД 50-34.698. Однако, в зависимости от сложности, назначения и области применения ПО, различные Руководства пользователя могут отличаться друг от друга по способу, методике и стилю изложения.
Заключение
Грамотно написанное Руководство пользователя может сэкономить значительное количество времени на обучение и адаптацию пользователя к программе, а также снизить количество ошибок в работе что, в свою очередь, повышает экономическую эффективность системы. Если вы не хотите вникать во все тонкости создания Руководства пользователя, но хотите иметь полный, качественный и полезный документ – обратитесь в компанию ТехРайтКонсалт, и мы применим весь наш опыт и знания для решения вашей задачи по доступной цене!
– разработка руководства администратора;
– создание руководства программиста;
– разработка руководства оператора.
Руководство по эксплуатации (РЭ) – это технический документ, включающий в себя сведения о конструктивных параметрах продукции, их составных элементах, принципе действия и технике безопасности во время использования и ремонта.
- Требования к руководству по эксплуатации
- Важные правила
- Кому может потребоваться руководство по эксплуатации?
- Какими ГОСТ и законами регламентируется порядок оформления документа?
- Каким должно быть содержание руководства по эксплуатации?
- Что может быть дополнительно?
- Как правильно оформить?
- Стиль оформления
Требования к руководству по эксплуатации
РЭ разрабатывается производителем в соответствии нормативными документами, регламентирующими изготовление продукции. Документ прилагается практически ко всем изделиям со сложной конструкцией или с особыми условиями использования.
Руководство по эксплуатации является добровольным документом, однако в некоторых случаях его наличие обязательно, т.к. является необходимым условием при оформлении разрешительных документов.
Например, если планируется использование товаров на опасных производствах. Содержание документа должно устранять все сомнения относительно правильной эксплуатации изделия.
Важные правила
Составление РЭ проводится в соответствии с определенными правилами:
- Цель документа – разъяснение. Потребитель с помощью него обеспечивается всей необходимой информацией по использованию продукции;
- Вся представленная информация должна соответствовать остальной технической документации;
- Руководство должно полноценно отражать принципы работы и эксплуатации данного изделия или продукции в целом;
- Вся информация не должна противоречить государственным стандартам и существующим техническим регламентам;
- Язык написания документа должен быть простым, понятным для всех, кто планирует эксплуатировать продукцию.
Кому может потребоваться руководство по эксплуатации?
Документ может быть необходим и быть полезен для:
- Аккредитованного центра при сертификации, для оценки качества и безопасности изделия;
- Сервисных сотрудников и служб, которые осуществляют обслуживание и ремонт оборудования;
- Надзорных и контролирующих органов, которые обязаны проверять соответствие использования техники и изделий на обеспечение техники безопасности;
- Потребителей, которые будут использовать данное изделие.
Какими ГОСТ и законами регламентируется порядок оформления документа?
Порядок оформления РЭ определен рядом нормативно-правовых документов и рекомендаций стандартов ЕСКД:
- ГОСТ 2.610-2006 – отражены общая система и правила тех. документов;
- ГОСТ 2.105-95 – отражены правила по тексту технической документации;
- ГОСТ 2.601-95 – указаны требования по оформлению РЭ;
- Также существуют требования, которые регламентируются Таможенным союзом: ТР ТС 016/2011, ТР ТС 010/2011 и другие.
- Для узконаправленной продукции оформление руководства по эксплуатации может еще регламентироваться дополнительными нормативами, например, Правилами безопасности оборудования.
Каким должно быть содержание руководства по эксплуатации?
Наполнение документа четко регламентировано, это позволяет пользователям быстро ориентироваться в информации и быстро осуществлять поиск нужных данных. Руководство по эксплуатации всегда состоит из обязательных разделов:
- Вводная часть;
- Оглавление;
- Подробное описание продукта, устройства или механизма;
- Комплектность;
- Подробное описание и условия его использования;
- Монтаж;
- Сервисное обслуживание, ремонт – указание возможных неполадок и способы их устранения;
- Применяемые к условию стандарты, требования и нормы безопасности;
- Гарантии производителя;
- Правила по хранению и транспортировке;
- Правила утилизации;
- Предметный указатель (глоссарий).
Что может быть дополнительно?
Дополнительно РЭ часто содержит:
- FAQ (часто задаваемые вопросы) и ответы на них;
- Ссылки на дополнительную информацию по сфере применения товара;
- Ссылки на обучающее видео;
- Популярные подсказки;
- Краткую аннотацию в начале каждого крупного раздела.
Т.к. изделием могут пользоваться разные группы людей, можно сделать разные разделы для разных категорий пользователей.
Как правильно оформить?
Составлением руководства по эксплуатации могут заниматься как сотрудники производителя, так и сторонние технические специалисты. Документ утверждается официально и является частью пакета технической документации на продукт. Т.к. РЭ обязательно требуется для процесса сертификации товара, часто за помощью в оформлении руководства обращаются к тем же сертифицирующим органам, где заказывают получение разрешительных документов. Для разработки руководства по эксплуатации необходимо предоставить максимально полное описание изделия, не только в текстовом виде, но и с чертежами, рисунками, таблицами, фотографиями.
Стиль оформления
Стиль оформления текста – деловой, нейтрально-формальный, без использования стилистические окрашенных слов, чтобы не отвлекать пользователей от сути документа. Важно не дублировать информацию, писать кратко и по сути. Последовательность данных должна походить на последовательность действий пользователя. Вежливые обороты («пожалуйста») не используются, только повелительное наклонение («возьмите», «соберите» и т.д.). Информация должна быть максимально структурирована, с использованием списков и нумерации. Внешний вид документа тоже должен быть продуман. Это может быть корпоративный шаблон, цветовая схема или специально созданный дизайн. Восприятие красиво оформленного РЭ может быть спроецировано на изделие и повлиять на решение его закупки и использования.