КомпанияУслугиОбучениеСервисы

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

Версия для печати

Михаил Острогорский, 2007 г.

Предпосылки к созданию технологических инструкций

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

Согласно определению, данному в ГОСТ 34.003-90, АС обязательно включает в себя технические средства, программное обеспечение и персонал. Например, Microsoft Excel как таковой – это программный продукт, а секретарь, который сидит за компьютером и записывает в размеченную определенным образом таблицу поступающие звонки – АС, хотя и совсем небольшая. Для описания ПО служат такие документы, как руководство пользователя, руководство системного администратора (следуя букве стандарта – системного программиста), руководство программиста. Предусмотрены различные документы для описания технических средств. Технологическая инструкция – наиболее «человечный» документ, он описывает действия участвующего в работе АС персонала, иначе говоря, пользователей. Вот формальная сторона дела.

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

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

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

Назовем несколько причин, по которым такое решение может оказаться неудачным.

Во-первых, одни и те же функции ПО могут использоваться разными сотрудниками при выполнении разных операций. Будем ли мы, описывая каждую операцию, многократно повторять описания одних и тех же программных функций? Если да, то документ сильно разрастется в объеме. Если нет, то описания такие описания придется «выносить за скобки»: помещать их в специальных разделах где-то в начале документа и давать на эти разделы ссылки из разделов, непосредственно описывающих операции. Но такое решение равносильно написанию двух документов, собранных под одной обложкой!

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

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

Содержание технологической инструкции

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

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

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

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

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

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

  • Триггер, т.е. событие или обстоятельство, при наступлении которого пользователь выполняет операцию. Триггером может быть какое-либо внешнее по отношению к пользователю событие (обращение контрагента, другого сотрудника, распоряжение начальника, поступление какого-то документа или сообщения), наступление определенного момента по установленному расписанию или собственное решение. Перечислять триггеры в описании операции необходимо, потому что ни один человек в здравом уме и твердой памяти не кидается выставлять счет ни с того ни с сего. Если не сообщить пользователю, когда он должен выполнять операцию, он не станет выполнять ее никогда.
  • Результат операции, т.е. существенное изменение ситуации, которое происходит после ее успешного выполнения. Результат не следует путать с выходными данными или документами. Так, подлинный результат выставления счета не бумага, а обязанность и/или возможность клиента заплатить нам, необходимость отследить поступление денег на расчетный счет, резервирование товара, если речь идет о счете на предоплату, и т.п.
  • Пошаговое описание выполнения операции, подробность и объем которого во многом определяются особенностями АС. Тем не менее, некоторые характерные его черты можно выделить. Каждый шаг описания касается какой-то одной задачи, решаемой либо посредством программного обеспечения, либо «в реальном мире». Например, задачей может быть вызов на экран некоторой формы и ввод в нее данных. Поиск твердой копии документа на стеллаже также может рассматриваться как отдельный шаг, только решение задачи не автоматизировано. При описании как автоматизированных, так и неавтоматизированных задач мы по возможности стараемся минимизировать количество технических подробностей. Описывая, предположим, заполнение формы, необходимо указать, какие поля являются обязательными, можно привести «скриншот» заполненной формы, но описание возможностей поиска нужного элемента в справочнике или работы с календарем для ввода даты уже будет излишним, таким сведениям самое место в руководстве пользователя или в контекстной справке.

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

Технологические инструкции и описания бизнес-процессов

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

Пользователи и их реакции на всевозможные события существуют объективно. Мы можем спросить конкретного менеджера или бухгалтера: «При каких обстоятельствах вы выставляете счет? Зачем вы это делаете? Что происходит после того, как вы это сделали?», и он, скорее всего, даст на этот вопрос четкий, хотя не всегда лаконичный ответ.

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

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

Формат публикации технологической инструкции

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

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

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

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

© «Философт», 2008–2017

+7 (499) 500-44-77

mail@philosoft.ru

SpyLOG