Что может входит в документацию пользователя
Делопроизводство в 1С
Понятия «Делопроизводство» и «Документооборот»
Ведение учета внутри компании непременно связано с обработкой множества бумажных документов. Оформление всех документов проводится через программу 1С:Документооборот которая автоматизирует и упрощает процесс создания и обращения всех бумаг. Этот процесс в программе называется делопроизводством.
Эти бумаги и файлы не остаются на месте – они непременно передаются в другие отделы, поставщикам, клиентам и другим партнерам, создаются специальные копии. Эти процессы называются документооборотом – обменом важными бумагами между сотрудниками компании и их правильное оформление для отправки партнерам.
Есть несколько весомых преимуществ такого документооборота. История взаимодействий и оформления заявок от одного отдела к другому хранится в системе и позволяют проверить всю работу сотрудников. К тому же, количество распечатанных бумаг, которые приходится хранить в офисе, заметно сокращается. Документооборот компании в программе 1С – это наиболее точный способ ведения внутреннего учета.
Типы документов в 1С Документооборот
Для правильного ведения учета операций, проходящих внутри организации, необходимо ввести определенную группировку. Все документы имеют свое направление – возможно, это внутренняя записка или счет на оплату, который пришел от поставщика. Документация разделяется на три потока, чтобы работа с ними велась отдельно и не пересекалась:
Перед тем как информация, полученная в документации от партнера, перейдет к другому партнеру (станет исходящим документом), она должна быть обработана. Доступ к документу ограничивается администратором, и каждый работник будет менять статус оформления документа в программе. По мере изменения статуса он будет переходить из отдела в отдел, а затем на его основе оформится исходящий документ.
Входящие документы
Входящими являются те документы, которые поступают в компанию извне.
Есть несколько источников:
Каждый из таких документов регистрируется и проходит три стадии обработки:
В 1С можно записывать документацию, которая поступает от физических или юридических лиц. Под входящими документами может пониматься счет на оплату, претензия и т.п. На каждое входящее обращение следует давать ответ, но перед этим придется поменять несколько статусов по каждому запросу.
Во-первых, при попадании к одному из сотрудников организации документация будет зарегистрирована. Она получит статус запроса. В ходе рассмотрения следует поставить статус «В обработке», и, после того, как решение будет принято, обработка подходит к стадии «Исполнение», а статус меняется на «Ответ на запрос».
Исходящие документы
Под исходящим документом понимается бумага, которая оформляется внутри организации для отправки партнерам или же надзорным органам. Так, например, при помощи 1С удобно формируются отчеты для налоговой инспекции. Легко здесь создать документы для создания заказа поставщику и отправления чека своим клиентам.
Исходящая документация может стать ответом на входящий запрос или же быть создана сама по себе. Она создается в несколько этапов:
В системе 1С фиксируется только последняя стадия создания – регистрация. Идентификационный номер должен присваиваться ответственным работником (чаще секретарем) после того, как текст пройдет согласование, корректировки и утверждение ответственными лицами. До этого документация существует традиционно только на бумаге.
Если исходящий документ является ответом на входящий запрос, такие документы связываются в системе. До того, как будет принято решение, входящий запрос будет «ждать» в статусе «В обработке», а когда исходящий документ будет сформирован, этой переписке будет установлен статус «Отправлен ответ».
Внутренние документы
Любое движение денежных средств и материалов должно регистрироваться документально. Если операции не записывать или же не зарегистрировать всего одну операцию, можно сбиться в счете – «пропадут» деньги или материалы. Наиболее надежным способом учета является использование компьютерной программы, в том числе 1С.
Внутренняя документация может являться частью обработки входящих или исходящих запросов. В процессе принятия решения необходимо фиксировать отпуск товара или разрешение на оплату по счету, потому что все эти действия являются частью обработки запросов. К внутренней документации относятся служебные записки, приказы и другие важные бумаги.
Виды документа
Вид – это параметр, который влияет на:
Для каждого потока исходящей документации существуют отдельные виды. Так, например, для внутреннего потока в 1С созданы следующие позиции:
В зависимости от потребностей и специфики работы организации можно создавать дополнительные виды документов с нужными полями. Стандартные шаблоны не всегда подходят, и поэтому в новых шаблонах можно изменить практически все параметры, чтобы сразу же можно было распечатать или отправить готовый документ, оформленный по стандартам компании.
Правила присвоения регномера
Регистрационный номер является главным реквизитом документа и является уникальным. Поиск отдельно взятой бумаги можно выполнить по номеру, поскольку идентичных сочетаний цифр не будет. Программа 1С ввела гибкую систему создания идентификационного номера. В него включаются и стандартные данных, и дополнительные.
В число стандартных данных, которые включаются в регистрационный номер, входит дата, вид, наименование корреспондента и подразделение, которое работает над документацией. Каждому виду и направлению присваивается свой номер. Его можно всячески видоизменять, чтобы по набору цифр было понятно, исходящий это запрос или входящий, а также какой отдел занимается его обработкой.
Каждый рабочий год регистрационные номера обновляются и начинаются с цифры 1. Также возможно присвоение совместного номера, когда в составлении документации участвовало несколько организаций. В этом случае под номером в базе данных ставится заметка о номере в базе данных другой компании. Короткие комбинации можно записывать в одну строку через дробь.
Учетно-регистрационная карточка
Для каждого документа независимо от его типа создается учетно-регистрационная карточка. Она напоминает функцию «Предпросмотр» в графических редакторах – здесь можно увидеть заполненный данными шаблон. Но это не все функции карточки – в ней есть несколько вкладок:
Таким образом, используя карточку, можно просмотреть историю создания и редактирования документации. Записываются все действия сотрудников – в случае возникновения вопросов можно узнать, к кому обратиться за разъяснениями. Простота и чистота такого способа учета позволяет быстро устранять ошибки.
Устройство 1С таково, что даже параметры в учетно-регистрационной карточке можно менять: поскольку специфика деятельности организаций может существенно отличаться, им необходимо настроить программу под себя. Без такого функционала 1С не стала бы таким полезным инструментом ведения учета для многих организаций.
Использование дополнительных параметров
Несмотря на то, что в оформлении и обработке документации присутствует определенная рутина, каждому документу требуется дополнительная настройка. Прежде всего, для него вводится расширенный список параметров, относящихся к каждому документу. Как пример, такими реквизитами могут быть:
Все эти параметры создаются для того, чтобы в несколько кликов заполнять документы, в которых будут отражаться действия сотрудников, движения денежных средств и материалов. Так записывается информация об отпуске и даже ведется отчетность о командировках – вводятся даты и список всех трат, которые компенсируют сотруднику.
Платформа 1С:Предприятие упрощает делопроизводство и делооборот внутри компании, поскольку делает эти процессы полуавтоматическими. Отдельные шаблоны уже включаются в программу, а сохранение истории взаимодействия сотрудников и обработки документации является базовой функцией программного обеспечения.
Как мы в «Активе» пишем пользовательскую документацию. Почему это важно
Что пользователь хочет видеть в пользовательской документации? Что его в ней раздражает? Эти вопросы задаёт себе каждый, кто пишет такую документацию, но далеко не каждый правильно отвечает на них. Совсем небольшой процент пользователей читает документацию. Давайте разберёмся, почему так и как сделать пользовательскую документацию эффективной и изменить отношение пользователей к ней.
Нам мешает негативный опыт
С такой ситуацией сталкивался почти каждый: вам надо быстро освоить какую-то ИТ-систему, она очень сложная, и в ней хранятся важные данные. Метод “проб и ошибок” здесь не подойдёт. Наверняка в такой момент вы вспомнили про руководство пользователя, открыли его и начали внимательно изучать. После 10 минут чтения вы ещё больше запутались, закрыли руководство и начали осваивать систему, используя при этом метод “будь что будет”. И хорошо, если при этом вы не удалили что-то очень важное и не получили результат, о котором будете жалеть, а ведь всякое бывает.
Да, через какое-то время вы всё-таки освоили систему и ловко жонглируете её процедурами, но чего это вам стоило? Вы потратили время, нервы и может даже не только свои. Что решило бы вашу проблему ещё на раннем этапе?
Ответ один — хорошая пользовательская документация.
Документация может всё
Пользовательская документация не только помогает быстро разобраться в ИТ-системе, она формирует позитивный пользовательский опыт и тем самым укрепляет репутацию продукта и компании в целом. Но не стоит забывать и о противоположной ситуации: плохая пользовательская документация помешает пользователю разобраться в ИТ-системе, сформирует негативный опыт и разрушит репутацию продукта и компании. Верю, что эта мысль понятна всем и здесь ничего не надо объяснять.
Давайте представим, что у вас уже есть документация. Вы видите, что пользователи её просматривают. Наряду с этим, количество звонков в техподдержку не уменьшается, и пользователи чаще всего спрашивают о том, что уже давно описано в документации. Почему так? Причин может быть много, я разберу только те, которые связаны именно с пользовательской документацией.
Это будет цикл статей, в которых я расскажу вам про основные ошибки в технической документации, мы посчитаем, сколько они стоят компании. Я объясню поведение пользователя, обозначу, с какими трудностями и эмоциями он сталкивается, когда читает плохой документ. Покажу, как можно исправить ошибки с минимальными затратами. Мои статьи для всех, кто пишет документацию и хочет делать это более осознанно, с заботой о пользователе. Если вы хоть в чем-то будете со мной не согласны, то пишите свои мысли в комментариях. Мы вместе можем сделать эту статью максимально полезной.
Процесс документирования в каждой компании выстроен по-своему. Где-то есть отдел технических писателей, отдел редакторов, отдел локализации технической документации, а где-то всю техническую документацию пишет один технический писатель. Но не стоит забывать о том, что написание документации – это всегда командная работа.
В этой статье я расскажу вам о том, сколько в нашей компании стоит пользовательская документация, и из каких этапов у нас состоит процесс документирования. Let’s go!
Сколько стоит пользовательская документация
Документация стоит денег, давайте разберёмся каких. Если в компании есть технический писатель, то стоимость документации не измеряется только его заработной платой. Расскажу, почему это так.
Рассмотрим на примере инструкции, которую можно написать за 20 часов. Технический писатель за это время напишет 25-страничный документ, в котором будет около 40 скриншотов.
Весь процесс производства инструкции в нашей компании состоит из следующих этапов:
1. Поставка задачи. Её создаёт и описывает менеджер проекта, руководитель проекта или руководитель отдела. На это нужно время, недостаточно просто написать “Опиши процедуру”. Здесь обязательно нужны детали. Например, здесь посчитаем 1 час рабочего времени менеджера проекта. На этапе постановки задачи менеджер проекта назначает консультанта и обозначает круг сотрудников компании, которые могут помочь и объяснят какие-то важные особенности системы. Получается, что цель этого этапа — сформулировать задачу и назначить консультанта
2. Показ системы. Чаще всего здесь задействован системный аналитик, он демонстрирует систему техническому писателю и рассказывает, что и как работает. Прибавим 2 часа работы аналитика + 2 часа технического писателя. Здесь аналитик рассказывает, а технический писатель слушает и задаёт вопросы. Если система сложная, таких встреч может быть несколько. Цель этого этапа — объяснить техническому писателю, как работает система.
3. Написание документа. Здесь главную роль играет технический писатель, но нельзя забывать про вопросы, которые у него могут возникать в процессе написания. Отвечать на них может аналитик, разработчик, менеджер проекта, тот, кто разбирается в продукте и умеет понятно объяснять. Таких вопросов может быть много и хорошо, если технический писатель оперативно получает на них ответы. Прибавим 20 часов работы технического писателя + 1 час работы аналитика + 1 час работы разработчика. Цель этого этапа — создать первую версию инструкции.
4. Рецензирование. Чаще всего читает документ заказчик, в нашем случае — менеджер проекта. На это тоже нужно время, оно зависит от количества страниц в документе и качества описаний. Прибавим 2 часа работы менеджера проекта. На этом этапе он пишет комментарии к документу. Цель этого этапа — проверить документ.
5. Внесение правок. Реализует технический писатель, на этом этапе он тоже может задавать уточняющие вопросы коллегам. Техническому писателю здесь очень важно правильно понять комментарии к инструкции. Прибавим 2 часа работы технического писателя + 1 час работы аналитика. Цель этого этапа — создать вторую версию документа.
6. Тестирование. На этом этапе подключается сотрудник отдела тестирования. Он реализует все описания процедур и оценивает насколько корректно они описаны. Прибавим здесь 2 часа работы тестировщика. Цель этого этапа — проверить корректность описания процедур.
7. Повторное внесение правок. Технический писатель получает от тестировщика комментарии и вносит изменения в инструкцию. Прибавим 1 час работы технического писателя. Цель этого этапа — создание третьей версии документа.
8. Вёрстка документа. Здесь может подключаться дизайнер. Если вёрстка не очень сложная, то технический писатель делает её сам. Прибавим 4 часа работы дизайнера. Цель этого этапа — сверстать документ так, чтобы его было удобно использовать.
9. Публикация документа. Мы публикуем документ на своём сайте на специальной странице. Прибавим 20 минут работы администратора сайта.
Итого:
Получается, что в нашей компании в процессе документирования задействованы 7 человек. У каждого есть своя роль в этом процессе и нельзя сказать, что кто-то менее или более важен. В вашей компании этот процесс может строиться иначе.
После такого подробного разбора наверняка стало понятно, почему стоит учитывать не только заработную плату технического писателя при оценке стоимости пользовательской документации.
100 тысяч рублей или долларов
Вы видите, что технический писатель не один участвует в создании инструкции. Здесь не обязательно называть какие-то точные цифры. Документация стоит денег и ошибки в ней — тоже. Именно поэтому её нужно сразу писать так, чтобы она решала задачи пользователя, приносила ему пользу, а не была чем-то бесполезным и просто “пылилась на полке”.
Сейчас, если в любом поисковике ввести слова “руководство пользователя”, то за 5 минут просмотра результатов вы найдёте как минимум 5 плохих документов и один хороший, а это совсем мало. Получается, что только каждый шестой документ является эффективным, а представьте сколько времени, денег потрачено впустую и надо здесь что-то менять. Давайте делать это вместе, так будет проще обратить внимание всех на эту проблему.
В следующей статье я расскажу про ошибки в документации. Отвечу на вопросы:
Что может входит в документацию пользователя
ГОСТ Р ИСО/МЭК 15910-2002
ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ПРОЦЕСС СОЗДАНИЯ ДОКУМЕНТАЦИИ ПОЛЬЗОВАТЕЛЯ ПРОГРАММНОГО СРЕДСТВА
Information technology.
Software user documentation process
ОКС 35.080
ОКСТУ 5001
Дата введения 2003-07-01
1 РАЗРАБОТАН И ВНЕСЕН Всероссийским научно-исследовательским институтом стандартизации (ВНИИстандарт) Госстандарта России
2 ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 25 июня 2002 г. N 249-ст
3 Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК 15910-99 «Информационная технология. Процесс создания документации пользователя программного средства»
Существующие стандарты можно отнести к двум основным типам:
a) стандарты на продукцию, определяющие ее характеристики и требования к ней;
b) стандарты на процессы, определяющие конкретные методы создания продукции.
Возрастающий масштаб применения программных средств и их сложность вызывает необходимость наличия полной, точной и понятной документации на эти средства, доступной пользователям. Настоящий стандарт определяет способ достижения данной цели, устанавливая работы (что должно быть сделано и исполнителя), связанные с качеством документации пользователя программных средств.
Документация часто рассматривает нечто, разрабатываемое после создания конкретного программного средства. Однако с точки зрения качества разработки программной документации она должна рассматриваться как неотъемлемая часть процесса создания данного программного средства. При надлежащем подходе к данной проблеме требуется достаточно сложная работа по планированию документирования. Целью настоящего стандарта является стимулирование разработчиков программных средств к надлежащему использованию процесса документирования. Стандарт также представляет пользователям метод определения надлежащего применения процесса документирования при создании конкретного программного средства.
Основной работой по настоящему стандарту является создание комплексного плана разработки документации, реализация которого обеспечивает лучшее документирование программного средства. Для соответствия настоящему стандарту данный план должен включать в себя требования (спецификацию) к стилю оформления документов. Настоящий стандарт не определяет состав данных требований (то есть компоновку конкретного документа или используемый шрифт), но устанавливает их диапазон. Стандарт также определяет виды информации, представляемой заказчиком разработчику документации (документатору) для проверяющих и распространяющих документацию.
Более подробная информация по данному вопросу приведена в библиографии.
1 Основной стандарт дополнен справочными приложениями, библиографией и тематическим указателем.
2 Исходный стандарт ИСО/МЭК 15910 разработан на основе австралийского стандарта AS 4258:1994.
3 Перечень дополнительных публикаций, связанных с тематикой настоящего стандарта, приведен в библиографии (см. [1]-[21]).
1 Область применения
Настоящий стандарт определяет минимально необходимый процесс создания документации пользователя всех видов для программного средства, имеющего интерфейс пользователя. Данные виды охватывают печатную документацию (например, руководства пользователя и краткие справочные карты), диалоговую (оперативную) документацию, справочный текст («хелпы») и системы диалоговой документации.
Стандарт соответствует требованиям 6.1 ГОСТ Р ИСО/МЭК 12207.
Применение настоящего стандарта должно обеспечить разработку документации, удовлетворяющей потребностям пользователя.
Стандарт предназначен для разработчиков и потребителей документации пользователя.
Настоящий стандарт используется для печатной документации, а также для справочных экранов, справочной системы обеспечения поставки, справочной информации и т.д.
Стандарт предназначен для применения при двусторонних отношениях и может быть использован, если обе стороны корпоративно связаны. Стандарт также может быть использован одной из сторон для самоконтроля.
Соответствие настоящему стандарту определяют по результатам демонстрации выполнения реализацией процесса, описанного в разделе 8.
3 Нормативные ссылки
В настоящем стандарте использованы ссылки на следующие стандарты:
ГОСТ 2.301-68 Единая система конструкторской документации. Форматы
ГОСТ Р ИСО 9127-94 Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов
ГОСТ Р ИСО/МЭК 12119-2000 Информационная технология. Пакеты программ. Требования к качеству и тестирование
ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств
ИСО 216-75* Бумага писчая и классы печатных материалов. Размеры обрезки. Серии А и В.
В настоящем стандарте использованы следующие термины с соответствующими определениями.
4.1 А4, A5: Размеры сторон листа 210х297 мм и 148х210 мм соответственно (см. ИСО 216, ГОСТ 2.301).
4.2 заказчик (acquirer): Организация, которая приобретает или получает систему, программный продукт или программную услугу от поставщика (3.1 ГОСТ Р ИСО/МЭК 12207).
4.3 аудитория (audience): Категория пользователей, предъявляющих к документации одинаковые или аналогичные требования и характеристики (например, в части использования документации, ее назначения, уровня обучения, возможностей и опыта персонала), определяющие содержание, структуру и назначение данной документации.
4.4 изучение аудитории (audience research): Планируемый процесс опроса потенциальных пользователей и анализа его индивидуальных и интегральных результатов.
4.5 В5: Размеры сторон листа 176х250 мм (см. ИСО 216).
4.6 вспомогательный материал (back matter): Материал, содержащийся в конце книги или руководства, например, тематический указатель.
4.7 фотошаблоны (camera-ready originals): Набор изображений на бумаге, фотопленке или другом носителе, с которого может быть сделана фотокопия, где каждое изображение содержит все необходимые текстовые и графические элементы одной страницы печатного документа, скомпонованные должным образом.
4.8 дата пересмотра (cut-off date): Дата, по истечении которой все изменения, внесенные в программные средства, описываются в новой редакции документации, более верной по сравнению с действующей.
4.9 номенклатура поставки (deliverables): Объекты (элементы, изделия и т.д.), поставляемые заказчику по условиям договора.
4.10 документ (document): См. элемент документации (4.26).
4.11 документация (documentation): Печатные руководства пользователя, диалоговая (оперативная) документация и справочный текст («хелпы»), описывающие как пользоваться программным продуктом.
4.12 персонал разработчиков документации (documentation development staff): Весь персонал, привлекаемый на любом этапе планирования, написания, редактирования и выпуска документации.
4.13 план документирования (documentation plan): Документ, в котором излагаются необходимые элементы проекта документирования.
4.14 документатор (documenter): Сторона, создающая документацию.
4.15 электронная копия (electronic copy): Компьютерный диск или другой машиночитаемый носитель информации, содержащий файл или файлы, с которого(ых) может быть распечатан документ.
4.16 n-штрих (en dash): Штрих, имеющий такую же ширину, как и строчная буква «n».
4.17 концевые примечания (endnotes): Примечания, собранные в конце главы или документа.
4.18 страница-раскладка (foldout): Страница, сложенная так, что ее задняя часть шире передней (немного превышает основной формат), которую можно развернуть.
4.19 нижний колонтитул (footer): Справочная(ые) строка(и) под текстом страницы, указывающая(ие) на ее содержание (например, номер страницы).
4.20 сноска (footnote): Помещаемый внизу страницы (колонки) текст (примечание, библиографическая ссылка и т.д.), связанный с основным текстом знаком сноски (цифровым номером, звездочкой), закрываемым круглой скобкой, набираемый обычно шрифтом пониженного кегля по сравнению со шрифтом основного текста и отделяемый от него пробелом или пробелом с тонкой короткой линейкой.
4.21 вводный материал (front matter): Начальная часть или глава издания, например, титульный лист и содержание.
4.22 верхний колонтитул (header): Справочная(ые) строка(и) над текстом страницы.
4.23 заголовок (heading): Название внутреннего подраздела издания, определяющее тему, раскрываемую в последующем тексте.
4.24 справочная система (help system): См. 4.32.
4.25 справочный текст (help text): Текст, облегчающий и убыстряющий пользователю, при эксплуатации программного средства, поиск содержащихся в издании объектов, автоматически выбираемый в зависимости от контекста, в котором он вызывается, т. е. справочный текст контекстно зависим.
4.26 элемент документации (item of documentation): Целевая информация, предназначенная для конкретной аудитории, размещенная на конкретном носителе (например, в книге, на диске, в краткой справочной карте) в заданном формате.
4.27 справочная ссылка (location reference): Метка, выделяющая заголовок или подзаголовок в тематическом (предметном) указателе, показывающая, к какой части документа они относятся.
4.28 измененный документ (изменение документа) (mark-up): Документ, содержащий заполненные листы изменений, а также процесс создания такого документа.
4.29 оригинал-макет (mechanicals): Оригинал, напечатанный как образец для набора, содержащий подробные текстовые, переплетные, издательские и компоновочные характеристики печатной продукции (издания).
4.30 навигация (navigation): Способ перехода пользователя от одной части прикладных программных средств к другой.
4.31 диалоговая документация (on-line documentation): Информация, доступная пользователю при эксплуатации программного средства, которая не обязательно привязана к конкретному контексту (см. также 4.25).
4.32 система диалоговой документации или справочная система (on-line documentation system or help system): Часть программы (иногда отдельная программа), запрашиваемая пользователем и позволяющая ему просматривать части диалоговой документации или справочного текста (см. также 4.25 и 4.31).
4.33 концевая висячая строка (orphan): Строка части текста (главы, раздела и т.д.) единственная на странице (полосе).
4.34 бумажный документ (orphan): Часть документации, представляемая в печатном виде.
4.35 элиз (доп. пиксель) (pixel): Наименьший элемент изображения на экране дисплея; сокращение от «элемент изображения» («picture element»).
4.36 точка (point): Единица типометрической типографской системы, выражаемая расстоянием по вертикали и содержащая в 1 мм приблизительно 2,8 точек (в одном дюйме приблизительно 72 точки).
4.37 процесс (process): Набор преобразующий исходные данные в выходные результаты (3.17 ГОСТ Р ИСО/МЭК 12207).