Написание процедур: ASP — Написание процедур

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

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

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

Характеристики процесса:

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

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

Характеристики процедуры:

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

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

Характеристика рабочей инструкции:

• Рабочая инструкция более детализирована
• Обычно описана в виде шагов или действий.

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

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

Менеджмент
79605

эксперт по системному бизнесу

Первое правило любого правила: Прочитать инструкцию или составить ее!

Неизвестный

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

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

Потаённая мечта руководителя

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

Ну чем не мечта руководителя? О том, имеют ли эти фантазии отношение к реальности, я и расскажу.

«В предыдущих сериях…» или «Ещё раз, почему регламенты и алгоритмы выгодны руководителю»      

В предыдущей статье “Система регламентов в компании как краеугольный камень эффективности руководителя” я подробно описал преимущества наличия системы регламентов. Повторение — мать учения. Поэтому привожу краткое содержание предыдущих серий.

Если сотрудник получает задание, которое он НЕ знает, “как выполнять” возможны два сценария:

• Сделает “хрен знает как”.
• Начнет всех спрашивать и отвлекать.

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

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

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

Ниже я привожу выдержки из алгоритма по составлению регламентов “Открытой Студии”. Копируйте, вносите “поправку на ветер” и внедряйте у себя в компании. Пристегнули ремни? Тогда поехали!

Алгоритм «Открытой Студии» по составлению регламентов

Как и что необходимо регламентировать

Если Вы столкнулись с проблемой / задачей, и предсказуемо, что она может повторяться в дальнейшем — значит она должна быть Вами регламентирована!

Любая повторяющаяся задача должна быть Вами регламентирована!

Запишите проблему в специальную таблицу “Лист разработки / дополнений регламентов «Открытой Студии»” и сообщите о ней исполнительному директору. (сотрудник может самовольно приступить к реализации только для инструкций, за которые он ответственен).

Мелкие и некритичные недочёты могут быть отмечены с помощью комментариев в соответствующем документе регламента (только для регламентов в GoogleDocs).

 Что будет, если я выполню всё по регламенту?

Критерии хорошего регламента

Регламент должен быть написан языком “блондинки”, т.е. как можно более наглядным. Желательно сопровождаться скриншотами.

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

Не забыть внести поправки в регламенты, находящиеся “сверху”, “снизу” и “сбоку” (изменился процесс у смежного объекта).

Если есть идея значительного изменения регламента, то для её оценки можно воспользоваться методикой “сплав по реке”:

• “Пройти вниз” по всем инструкция и определить последствия планируемых изменений.
• Если всё “ОК”, то обновить все смежные регламенты. Желательно, чтобы изменения вступили в действие в один день.

Алгоритм написания пошаговой инструкции

1. Описать инициирующее событие.
2. Описать процедуры и операции в верном порядке (используем принцип “Декомпозиции”)

• Процедура: единство времени и действия, одна цель (пример для продавца киоска: отпереть киоск утром, отмазаться от проверяющего и т.д.). Состоит из операций.
• Операция: отключение сигнализации, отпирание входной двери и т.д. (единичное действие).

• Необходимо проставлять кросс-ссылки на другие документы (см. ниже “Разделение регламентов и ссылки на дополнительные регламенты”).
• Использовать уже готовые регламенты и ссылаться на них, а не копировать их содержимое (чтобы избегать одновременного внесения изменений в 2 и более документа одновременно).

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

• Выстраивать “Цепочки контроля” (если подразумевается, что работу выполняют последовательно несколько людей, и кто-то получает на вход результаты от другого)
• Каждый сотрудник, начиная со второго и дальше, перед тем как выполнить свою работу, проверяет работу выполненную перед ним.
• Кого необходимо наказывать в случае обнаружения “брака”? Ответ: того, кто допустил брак / косяк, и того, кто его работу не проверил.

• Кому подчиняешься ты, кто подчиняется тебе.

Методика проверки инструкции исполнительным директором

• Проверить соблюдение “Правила оформления регламента” (см. ниже).
• Выполнить то, что описано в инструкции, либо посадить перед собой человека-тестера (который желательно никогда в жизни эту работу не делал) и рядом с ним наблюдать за всеми его косяками и вопросами. Фиксировать всё. По итогам поставить задачу на доработку инструкции либо дополнить её самому.

 Ввод в действие новых регламентов может вызвать бурную реакцию!

Ввод в действие регламентов

Правила оформления регламента

• Для каждого регламента необходимо создать автоматическое оглавление (в GoogleDocs: “Insert” → “Table of contents”)
• Частицу “не” необходимо писать большими буквами и выделять жирным, получится: “НЕ” 
• Соблюдать иерархию в заголовках <h2> — <h6>, заголовок <h2> должен быть только один на весь документ — и это название регламента.
• Между предыдущим абзацем текста и следующим за ним заголовком ставить пустую строку (между заголовком и следующим за ним текстом — НЕ надо). 
• Текст под заголовками начинать с маркированного списка. Не пренебрегайте и другими правилами по улучшению читабельности текста.
• Если размещается скриншот, то
• он должен сразу следовать за информацией, которую он поясняет.
• в конце последнего предложения перед скриншотом должна быть фраза “(см. скриншот ниже, возможно, скриншот перенесён на следующую страницу документа”)
• если скриншот большой, то он переносится на следующую страницу и создаётся впечатление, что дальше текста нет)

• После каждого дополнения регламента необходимо прокручивать вверх и нажимать на кнопку “обновить оглавление”.

 В хорошем регламенте проставлены ссылки на все ответвления

Ветвление регламентов и ссылки на дополнительные регламенты (на примере сервиса Google Docs)

Если информация переносится из одного регламента в другой, то необходимо оставить основной заголовок + надпись наподобие “Все вопросы по заключению договоров см. документ “Работа c договорами и официальными документами в «Открытой Студии»”.

Правила работы с кросс-ссылками в регламентах

• установка локальных ссылок в документе
• выделить заголовок, на который планируешь ссылаться
• выбрать в верхнем меню “Insert → Bookmark”
• перейти на место, откуда будешь ссылаться в том же документе
• выделить анкор (текст ссылки) и выбрать “Insert → Link → Bookmarks”.

• установка глобальных ссылок на другие документы
• Необходимо использовать текст (анкор) для ссылки, а не постить url-ссылки.
• в качестве текста ссылки необходимо взять название документа + заголовок, на который будет переход в другом документе.
• для того чтобы в документе, куда ведёт ссылка, произошёл переход именно в нужно место, необходимо в нём сначала кликнуть по искомому заголовку в оглавлении и только после этого можно скопировать эту ссылку из строки браузера для вставки.
• Кстати, глобальные ссылки в GDocs при перемещении документов между папками и переименовании документов СОХРАНЯЮТСЯ.

 Шаблоны для типовых документов — хорошее дополнение к регламентам

Разработка шаблонов документов

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

• Решение о разработке шаблона документа Сотрудник согласовывает с исполнительным директором, как и сам итоговый результат на выходе.
• Самостоятельное изменение существующих шаблонов документов запрещается без согласования планируемых правок с исполнительным директором.
• Если возникла идея дополнить шаблон, то её надо записывать в специальную таблицу “Лист разработки / дополнений регламентов «Открытой Студии»” и после этого обсуждать с исполнительным директором:
• Все новые документы необходимо создавать на основе шаблонов, а НЕ на основе аналогичных документов, разработанных ранее. Так как шаблон постоянно дорабатывается, то он всегда актуальнее.

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

Рекомендуемые услуги «Открытой Студии»

Написание процедуры Function (VBA) | Microsoft Docs

• 
  12/26/2018
• Чтение занимает 2 мин

В этой статье

Процедура Function — это последовательность операторов Visual Basic, заключенных в операторах Function и End Function .A Function procedure is a series of Visual Basic statements enclosed by the Function and End Function statements. Процедура Function аналогична процедуре Sub , но функция также может возвращать значение.A Function procedure is similar to a Sub procedure, but a function can also return a value.

Процедура Function может принимать аргументы, например константы, переменные или выражения, которые передаются ей вызывающим кодом.A Function procedure can take arguments, such as constants, variables, or expressions that are passed to it by a calling procedure. Если в процедуре Function нет аргументов, оператор Function содержит пустые скобки.If a Function procedure has no arguments, its Function statement must include an empty set of parentheses. Функция возвращает значение, присваивая его собственному имени в одном или нескольких операторах данной процедуры.A function returns a value by assigning a value to its name in one or more statements of the procedure.

В следующем примере показано, как с помощью функции Celsius можно преобразовать градусы Фаренгейта в градусы Цельсия.In the following example, the Celsius function calculates degrees Celsius from degrees Fahrenheit. Если функция вызывается из процедуры Main, переменная, которая содержит значение аргумента, передается функции.When the function is called from the Main procedure, a variable containing the argument value is passed to the function. Результат вычислений отображается в вызывающем коде, который виден в окне сообщения.The result of the calculation is returned to the calling procedure and displayed in a message box.

Sub Main() 
 temp = Application.InputBox(Prompt:= _ 
 "Please enter the temperature in degrees F.", Type:=1) 
 MsgBox "The temperature is " & Celsius(temp) & " degrees C." 
End Sub 
 
Function Celsius(fDegrees) 
 Celsius = (fDegrees - 32) * 5 / 9 
End Function

См. такжеSee also

Поддержка и обратная связьSupport and feedback

Есть вопросы или отзывы, касающиеся Office VBA или этой статьи?Have questions or feedback about Office VBA or this documentation? Руководство по другим способам получения поддержки и отправки отзывов см. в статье Поддержка Office VBA и обратная связь.Please see Office VBA support and feedback for guidance about the ways you can receive support and provide feedback.

Написание процедуры Property (VBA) | Microsoft Docs

• 
  12/26/2018
• Чтение занимает 2 мин

В этой статье

Процедура Property — это ряд операторов Visual Basic, которые позволяют программистам создавать настраиваемые свойства и управлять ими.A property procedure is a series of Visual Basic statements that allow a programmer to create and manipulate custom properties.

• Процедуры Property можно использовать для создания свойств, открытых только для чтения, в формах, стандартных модулях и модулях классов.Property procedures can be used to create read-only properties for forms, standard modules, and class modules.

• Процедуры Property следует использовать вместо переменных с атрибутом Public в коде, который должен выполняться при установке значения свойства.Property procedures should be used instead of Public variables in code that must be executed when the property value is set.

• В отличие от общедоступных переменных, процедурам свойств могут быть назначены строки справки в обозревателе объектов.Unlike Public variables, property procedures can have Help strings assigned to them in the Object Browser.

При создании процедуры Property она становится свойством модуля , содержащего процедуру.When you create a property procedure, it becomes a property of the module containing the procedure. Visual Basic предоставляет следующие три типа процедур свойств.Visual Basic provides the following three types of property procedures.

Для объявления процедуры Property используется следующий синтаксис:The syntax for declaring a property procedure is as follows.

[ Общедоступная | Частная ] [ Static ] Свойство { Get | let | Set } PropertyName [( аргументы )] [ as Type ] Операторы End Property[ Public | Private ] [ Static ] Property { Get | Let | Set } propertyname [( arguments )] [ As type ] statements End Property

Процедуры свойств обычно используются в парах: свойство Let со свойством Getи набор свойств со свойством Get.Property procedures are usually used in pairs: Property Let with Property Get, and Property Set with Property Get. Объявление только процедуры Property Get аналогично объявлению свойства, открытого только для чтения.Declaring a Property Get procedure alone is like declaring a read-only property. Совместное использование всех трех типов процедур свойств полезно только для переменных Variant , так как только объект Variant может содержать либо объект, либо другие сведения о типе данных.Using all three property procedure types together is only useful for Variant variables, because only a Variant can contain either an object or other data type information. Процедура Property Set рассчитана на использование с объектами, в отличие от процедуры Property Let.Property Set is intended for use with objects; Property Let isn’t.

В приведенной ниже таблице показаны обязательные аргументы в объявлениях процедуры свойств.The required arguments in property procedure declarations are shown in the following table.

Первый аргумент с помощью следующего аргумента (1,…, n) должен иметь одни и те же имена и типы данных во всех процедурах свойства с одинаковыми именами.The first argument through the next to last argument (1, …, n) must share the same names and data types in all property procedures with the same name.

Для объявления процедуры Property Get требуется на один аргумент меньше, чем для объявления связанных процедур Property Let и Property Set.A Property Get procedure declaration takes one less argument than the related Property Let and Property Set declarations. Тип данных для процедуры Property Get должен совпадать с типом данных последнего аргумента (n + 1) в соответствующих объявлениях Property Let и Set Property .The data type of the Property Get procedure must be the same as the data type of the last argument (n +1) in the related Property Let and Property Set declarations. Например, при объявлении следующей процедуры Property Let имена и типы данных аргументов процедуры Property Get должны совпадать с именами и типами данных аргументов процедуры Property Let.For example, if you declare the following Property Let procedure, the Property Get declaration must use arguments with the same name and data type as the arguments in the Property Let procedure.

Property Let Names(intX As Integer, intY As Integer, varZ As Variant) 
 ' Statement here. 
End Property 
 
Property Get Names(intX As Integer, intY As Integer) As Variant 
 ' Statement here. 
End Property 

Последний аргумент процедуры Property Set должен быть объектного типа или типа Variant.The data type of the final argument in a Property Set declaration must be either an object type or a Variant.

См. такжеSee also

Поддержка и обратная связьSupport and feedback

Есть вопросы или отзывы, касающиеся Office VBA или этой статьи?Have questions or feedback about Office VBA or this documentation? Руководство по другим способам получения поддержки и отправки отзывов см. в статье Поддержка Office VBA и обратная связь.Please see Office VBA support and feedback for guidance about the ways you can receive support and provide feedback.

Как правильно писать хранимые процедуры в SQL Server

Оригинал

Сегодня я бы хотел обсудить с вами тему хранимых процедур в SQL Server 2000-2005. В последнее время их написание занимало львиную долю моего времени на работе и чего уж тут скрывать – по окончанию работы с этим делом осталось достаточно информации, которой с удовольствием поделюсь с тобой %пользовательимя%.
Знания, которыми я собираюсь поделиться, к сожалению,(или к счастью) не добыты мной эмперически, а являются, в большей степени, вольным переводом некоторых статей из буржуйских интернетов.
Итак, как можно понять из названия речь пойдет об оптимизации. Сразу оговорюсь, что все действия, которые я сейчас буду описывать, действительно дают существенный(некоторые больший, некоторые меньший) прирост производительности.
Данная статья не претендует на полное раскрытие темы оптимизации, скорее это собрание практик, которые я применяю в своей работе и могу ручаться за их эффективность. Поехали!

Включай в свои процедуры строку — SET NOCOUNT ON:

С каждым DML выражением, SQL server заботливо возвращает нам сообщение содержащее колличество обработанных записей. Данная информация может быть нам полезна во время отладки кода, но после будет совершенно бесполезной. Прописывая SET NOCOUNT ON, мы отключаем эту функцию. Для хранимых процедур содержащих несколько выражений или\и циклы данное действие может дать значительный прирост производительности, потому как колличество трафика будет значительно снижено.

CREATE PROC dbo.ProcName
AS
SET NOCOUNT ON;
—Здесь код процедуры
SELECT column1 FROM dbo.TblTable1
—Перключение SET NOCOUNT в исходное состояние
SET NOCOUNT OFF;
GO

Используй имя схемы с именем объекта:

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

SELECT * FROM dbo.MyTable —Вот так делать хорошо
— Вместо
SELECT * FROM MyTable —А так делать плохо
—Вызов процедуры
EXEC dbo.MyProc —Опять же хорошо
—Вместо
EXEC MyProc —Плохо!

Не используй префикс «sp_» в имени своих хранимых процедур:

Если имя нашей процедуры начинается с «sp_», SQL Server в первую очередь будет искать в своей главной базе данных. Дело в том, что данный префикс используется для личных внутренних хранимых процедур сервера. Поэтому его использование может привести к дополнительным расходам и даже неверному результату, если процедура с таким же имененем как у вас будет найдена в его базе.

Используй IF EXISTS (SELECT 1) вместо IF EXISTS (SELECT *):

Чтобы проверить наличие записи в другой таблице, мы используем выражение IF EXISTS. Данное выражение возвращает true если из внутреннего выражения возвращается хоть одно изначение, не важно «1», все колонки или таблица. Возращаемые данные, в принципе никак не используются. Таким образом для сжатия трафика во время передачи данных логичнее использовать «1», как показано ниже:

IF EXISTS (SELECT 1 FROM sysobjects
WHERE name = ‘MyTable’ AND type = ‘U’)

Используй TRY-Catch для отлова ошибок:

До 2005 сервера после каждого запроса в процедуре писалось огромное колличество проверок на ошибки. Больше кода всегда потребляет больше ресурсов и больше времени. С 2005 SQL Server’ом появился более правильный и удобный способ решения этой проблемы:

BEGIN TRY
—код
END TRY
BEGIN CATCH
—код отлова ошибки
END CATCH

Facebook

Twitter

Вконтакте

Google+

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

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

А структура инструмента зависит от структуры управления. Конечно, можно просто принять содержание и структуру “по умолчанию”, но тогда это будет уже из разряда:

Хорошо быть девочкой в розовом манто. Можно и не в розовом, но уже не то.

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

• Принятые в компании носители документов – у вас принято работать “с бумагой” или “цифрой”? Спойлер – настоятельно рекомендую использовать электронные версии регламентов.
• Процессы согласования, изменения и управления регламентами.
• Степень зрелости бизнес процессов.
• Состав и точки зрения заинтересованных сторон на бизнес процесс.
• Требования заинтересованных сторон к регламенту.
• Цели и задачи, которые регламенты выполняют в компании.

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

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

Раздел 1 – Краткое описание

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

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

Все пункты краткого описания обязательны для размещения.

• Название процесса. Несмотря на то, что в регламенте указывается заранее определенное название процесса, все же еще раз напомню. Название процесса должно быть уникальным и отражать его суть. Быть уникальным – это значит, что второго такого названия процесса или функции не существует в вашей компании.
• Сквозной номер процесса. Если у вас используется нумерация процессов, то номер должен быть указан здесь. Если нумерации нет – просто пропустите этот пункт. Как правило, если вы используете информационную систему для управления регламентами, то потребность в нумерации отпадает.
• Тип процесса. К какому типу относится процесс: основной, вспомогательный или процесс управления.
• Цель / назначение процесса. Очень краткое описание того, зачем существует и какие цели преследует бизнес процесс. Описание должно быть таким, чтобы читателю сразу стало понятно, о чем речь.
• Владелец процесса. Имя, должность и структурная организационная единица, к которой относится владелец процесса. Можно сразу указать или дать ссылку на контакты владельца процесса. Информация о должности и принадлежности к организационной единице нужна для того, чтобы читателю было понятно – в чьей со структурной точки зрения зоне ответственности находится данный процесс.
• Основное событие начала. Основное событие, которое стартует выполнение процесса. Событий начала может быть множество, но всегда существует основное – это такое событие, которое инициирует выполнение процесса с наибольшей вероятностью.
• Основной вход. Входов также может быть несколько, но всегда есть что-то самое главное, с чем работает процесс. И да, это может быть целый набор.
• Основной поставщик. Название внутреннего процесса, который поставляет вход в рассматриваемый процесс. Если же вход поступает из внешнего источника, то указываем как есть. Например, Поставщик А или Поставщик конкретного продукта. Либо любое другое название, которое позволит однозначно понять, кто вне компании отвечает за поставку входа в процесс.
• Основное событие окончания. Событие или условие, при выполнении которого мы считаем процесс завершенным. Событий окончания может быть несколько, но, как правило, только одно является основным, потому что только при наступлении этого события, процесс достигает своей цели. Все остальные события окончания являются отклонениями от основного, желаемого сценария и в этом разделе не указываются.
• Основной продукт. Многие процессы производят несколько продуктов. Они могут быть основными (как правило, основной продукт один) и второстепенными. Основной продукт – это то, ради чего существует весь процесс. Ради этого продукта все выполняется.
• Основной клиент. У любого продукта есть клиент. Внутренний или внешний. В кратком описании обязательно указать – кто является клиентом рассматриваемого процесса. Под “кто” я понимаю внутренний процесс, конкретное лицо, организационную единицу или внешнего клиента.

Раздел 2 – Границы процесса

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

Входы

Обязательно

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

Желательно

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

События начала

Обязательно

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

Желательно

• Инициатор события – если событие является следствием другого процесса, порождается одним из внутренних или внешних участников, то это необходимо указать. Например, если событием начала является «Получена заявка клиента», то инициатором будет сам клиент. Если мы говорим о процессе Обработка заявок клиентов. Если же заявка поступает в процесс Сборки заказа, то она может поступать из процесса Обработка заявок клиентов.
• Связанный вход – если вместе с событием поступает вход (а такое, как вы уже знаете, происходит далеко не всегда), то нужно указать, какой вход связан с событием начала. Из вышеуказанного примера: если событием начала является Получена заявки клиента, то связанным входом будет заявка. Этот пример прост и очевиден, но часто все не так просто.

Продукты

Обязательно

• Название продукта – название продукта, который производит процесс.
• Тип продукта. Как я говорил ранее, есть основные и второстепенные продукты. Основной продукт – это то, ради чего существует процесс. Получение основного продукта – это основная задача процесса. Второстепенные продукты – все остальное, что появляется в результате выполнения процесса и используется где-то еще. С этой точки зрения первичная документация, которая появляется в результате процесса продаж, является второстепенным продуктом.
• Клиент – у каждого продукта, основного или второстепенного, должен быть клиент. Если клиента не существует, то процесс не нужен. В регламенте процесса обязательно нужно указать, кто является клиентом каждого продукта.
• Характеристики продукта – перечислите характеристики продуктов процесса, которыми они, продукты, обязательно должны обладать до передачи клиенту. Если вернуться к примеру с первичной документацией, то такими характеристиками могут быть: наличие печати и подписи поставщика, наличие подписи ответственного за прием продукции и так далее. Также к характеристикам можно отнести результат выполнения определенных операций. Например, документ проверен до передачи в бухгалтерию. Регламент процесса не может существовать без описания характеристик продуктов.
• Требования к продукту – требования к продукту задает его клиент. Требования обязательно вносить в регламент процесса. Это позволит в любой момент проверить, насколько процесс обеспечивает выполнение требований к продукту. Список требований также необходимо рассматривать в качестве соглашения между участниками процесса и его клиентами. Соглашение – это договоренность о том, что участники берут на себя обязательства выполнить требования через механизм реализации процесса.

Желательно

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

События окончания

Обязательно

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

Желательно

• Где фиксируется событие. Если событие окончания где-то фиксируется, будь то информационная система, документ, журнал, или просто мелом на  заборе, то совсем не лишним будет это указать в регламенте.
• Связанный продукт. Если вместе с событием окончания связан какой-то продукт процесса, это также желательно указать. Иногда это очевидно, но иногда вовсе нет.
• Что инициирует событие. Очень часто, но не всегда событие окончания одного процесса одновременно является событием начала другого процесса. В таком случае будет правильно указать процесс, который «стартует» благодаря событию окончания рассматриваемого процесса.

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

Это можно сделать с помощью правильного наименования. Если один процесс завершается событием “Отчет Х отправлен”, то связанное событие начала должно называться “Отчет Х получен”.

Раздел 3 – Выполнение процесса

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

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

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

Процедуры, бизнес правила и скрипты

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

Обязательно

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

Желательно

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

Время выполнения операций

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

Обязательно

• Наименование операции
• Минимальное время выполнения
• Среднее время выполнения
• Максимальное время выполнения

Участники процесса

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

Обязательно

• Роль участника
• Количество единиц, необходимых для выполнения процесса. Обратите внимание, это не количество человек, которое участвует в выполнении процесса. Количество единиц – это количество каждой роли, которая нужна для выполнения процесса один раз. Если в процессе обслуживания клиентов есть роль «специалист по продажам», то количество будет 1, если только у вас не принято работать с клиентом сразу двум специалистам. При этом роль “кассир”, которая также может быть в данном процессе, может выполняться тем же человеком, который выполняет роль специалиста по продажам.  Если говорить о процессе монтажа оборудования, в котором задействована целая монтажная бригада, то в таком процессе количество единиц в роли «монтажник» будет явно не 1.

Желательно

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

Матрица “роль-должность”

Ресурсы и инфраструктура

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

Обязательно

• Ресурс – собственно наименование ресурса, который используется в процессе.
• Учетная единица – килограммы, штуки, метры, борзые щенки и так далее.
• Количество на процесс (норматив) – принятое количество, которое используется или расходуется в процессе.
• Источник / где взять – где сотрудник может взять этот ресурс, если это необходимо.

Желательно

• Тип ресурса – намного лучше, когда ресурсы разбиты по типам. При этом типы ресурсов могут соотноситься с типами согласно управленческого и/или бухгалтерского учета. Это позволит упростить анализ. Наиболее распространенные типы ресурсов:
  • • Сырье
    • Инструменты
    • Программное обеспечение
    • Запасные части и комплектующие
    • Расходные материалы
    • Информация / данные
    • Оборудование
• Способ потребления в процессе – разные ресурсы по-разному используются в процессе. Разница заключается в том, как расходуется ресурс. Проще говоря, можно ли использовать ресурс много раз, как, например, инструменты и оборудование, или ресурс расходуется полностью, как сырье. От этого зависит расчет стоимости процесса, планирование обеспечения ресурсами, анализ процесса. Стоит выделить следующие типы способов потребления:
  • • Многократное использование – оборудование, программное обеспечение, инструменты. Все это может использоваться многократно без потери своих свойств. С точки зрения учета такие ресурсы имеют стоимость использования в единицу времени. Как правило, в час.
    • Используется частично – некоторые ресурсы могут использоваться частично. Это значит, что после использования останется некоторое количество. Рассчитывается эквивалентно проценту расходования.
    • Используется полностью – как правило, сырье и расходные материалы используются полностью, то есть без остатка. В таком случае учитывается полная стоимость израсходованного ресурса.
• Стоимость единицы – стоимость учетной единицы ресурса.
• Стоимость на процесс – стоимость ресурса в соответствии с количеством, которое используется в процессе и способом потребления.
• Матрица использования ресурсов – матрица соотношения используемых в процессе ресурсов и операций. Проще говоря, отмечаем – какие ресурсы и в какой операции используются. В виде матрицы имеет смысл отображать только для операций.

Матрица использования ресурсов

Документы процесса

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

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

Обязательно

• Наименование документа
• Дата выпуска документа – дата вступления в силу
• Ссылка на документ – как правило, нет смысла прикладывать все документы к регламенту и можно просто дать ссылку на документ в электронном виде или указать, где его можно найти.

Желательно

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

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

Всегда старайтесь избегать дублирования.

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

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

Раздел 4 – Управление процессом

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

Матрица ответственности

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

Матрица ответственности управления процессом

В такой матрице основным принципом построения является отношение участников процесса к управленческому циклу, а точнее, к его расширенному варианту:

• Планирование
• Организация
• Выполнение
• Контроль
• Улучшение / изменение

Один и тот же участник не может выполнять операцию и контролировать ее выполнение!

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

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

Матрица ответственности управления процессом

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

Матрица ответственности выполнения подпроцессов / этапов процесса.

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

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

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

Матрица ответственности за выполнение процесса

Матрица ответственности – это не обязательная, но весьма полезная составляющая регламента процесса.

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

Осуществление управления

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

Ключевые требования

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

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

Все поля обязательно указывать

• Требование – краткое наименование требования
• Тип требования – к чему относится требование: продукт, ход процесса и т.д.
• Описание – описание требования, достаточное для понимания того, что имеется в виду и как это выражается в процессе
• Источник требования – внешний или внутренний источник требования. Внутренним источником, как правило, является или какой-то документ (например, приказ), или некое заинтересованное лицо. Чаще всего таким лицом является владелец другого процесса. Внешние требования тоже часто закреплены в документах, однако некоторые требования могут существовать в виде договоренностей с внешними сторонами. Это ни в коем случае не исключает требование из списка. Более того, порой соблюдение таких договоренностей может иметь даже большее значение.
• Механизм обеспечения – поле, которое не всегда используется, но может иметь существенное значение. Каждое требование должно выполняться через сам процесс. Это значит, что процесс должен быть выстроен таким образом, чтобы требование гарантированно выполнялось. Иногда имеет смысл дополнительно объяснить, через какие действия в процессе обеспечивается выполнение требования.

Показатели бизнес процесса

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

Обязательно

• Показатель – наименование показателя
• Формула расчета – формула, по которой рассчитывается данный показатель
• Где фиксируется – необходимо указать, в какой системе или документе происходит запись показателя.
• Способ фиксации – существует два способа: вручную или автоматически. Да, если показатели не фиксируются автоматически в некой системе, это вовсе не повод отказываться от его фиксации и дальнейшего анализа. Просто это придется делать руками.
• Стандартный диапазон значений – диапазон значений, который принят в качестве стандартного для данного показателя. Можно указывать диапазон в виде «от… до …», но я бы рекомендовал использовать 3 варианта значений: минимальное, среднее и максимальное.

Желательно

• Краткое описание показателя – наименование показателя не всегда отражает его суть, поэтому может быть полезным объяснить, что отражает показатель.
• Тип показателя. Есть 3 основных типа показателя процесса:
  • • Показатели хода процесса – время выполнения процесса, стоимость процесса и так далее.
    • Показатели продукта процесса – показатели, которые отражают характеристики продуктов процессов. Например, количество изделий, которые выпускает процесс за один подход.
    • Клиентские показатели. Фактически это показатели удовлетворенности клиентов процесса. Например, количество не принятых клиентом изделий.
• Источник данных – указание источника данных позволяет убрать вопросы, связанные с релевантностью исходных данных. Кроме того, некоторые показатели могут выводиться на основании нестрогих методов анализа. В таком случае особенно важно объяснить источник.
• Действия при отклонении – при правильной организации процессного управления существует специальный процесс, который запускается в случае возникновения отклонения для любого процесса. Но в определённых случаях в процессе могут существовать специальные процедуры и мероприятия для таких случаев. Если такие есть, то укажите их здесь.
• Периодичность мониторинга – с какой частотой человек, который несет ответственность за контроль показателя, наблюдает за ним и производит анализ.
• Ответственный за мониторинг – собственно это тот, кто отвечает за наблюдение за показателем.
• Представление для анализа – где можно ознакомиться с показателем. Это может быть система, специфическая выгрузка из системы, отчет или какой-то иной документ.

Приложения

• Связанные документы и нормативные ссылки. Когда регламент выполняет в том числе формальную функцию, может быть, необходимо указать связь регламента с внутренними и внешними документами, а также дать нормативные ссылки. Необязательный пункт.
• Ревизия процесса. Указывается дата ревизии, кто провел и что в итоге: были внесены изменения или нет. Под ревизией имеется в виду, что кто-то посмотрел, как работает процесс и соответствует ли реальная жизнь тому, что написано в регламенте.
• Перечень изменений. Перечень внесенных в регламент изменений с указанием даты и лица, внесшего изменение.
• Словарь терминов и сокращений – думаю, тут все понятно.
• Условные обозначения. Перечень значений элементов нотации, в которой выполнены модели процессов.
• Формы и образцы документов. Если вы решили, что регламент должен включать в себя образцы и формы документов, то лучше всего это сделать в виде приложения.

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

Чаще всего можно увидеть регламент процесса, в котором общие положения вынесены в начало документа. Да ладно! Вот скажите, кто-нибудь реально это читает? Нет? Ну а раз нет, значит, это не нужно. Почти.

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

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

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

На этом, пожалуй, все. В качестве завершения, хочу еще раз обратить внимание на несколько важных вещей:

1. Регламент процесса должен быть понятен. Это значит, что если понятия и термины, которые используются в регламенте, могут быть непонятны в вашей компании, используйте свои. Упрощайте язык. Пусть будут не входы, а “то, что нужно для начала процесса”. Пусть будет не продукт процесса, а “результат”. Пусть будет не событие начала, а “старт” или “условие начала”. А так далее.
2. Вводите термины и определения постепенно. Нужно время, чтобы новые термины прижились.
3. Согласовывайте регламент по мере его разработки. Вовлекайте заинтересованные стороны в его создание. Сопричастность позволяет снизить уровень сопротивления.
4. Используйте информационные системы! Уходите от бумажных регламентов!

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

О том, как заставить регламент работать, можно прочитать здесь.

Подписывайтесь на нашу новостную рассылку, чтобы не пропустить новые статьи.

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

функции и процедуры в 1С часть 1

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

Войдите на сайт как ученик

Войдите как ученик, чтобы получить доступ к материалам школы

Внутренний язык программирования 1С 8.3 для начинающих программистов: функции и процедуры в 1С часть 1

Автор уроков и преподаватель школы: Владимир Милькин

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

Функции и процедуры в языке 1С 8.3

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

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

А = 0;
ВвестиЧисло(А);
Б = 0;
ВвестиЧисло(Б);
Результат = (А + Б) * (А - Б);
ОткрытьЗначение(Результат);

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

Неужели нам снова и снова придётся писать код для её вычисления:

Результат = (А + Б) * (А - Б);

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

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

Пусть этим именем будет ПроизведениеСуммыИРазности.

Получается теперь мы можем написать:

Результат = ПроизведениеСуммыИРазности;

И всё? Нет, конечно! Ведь непонятно произведение суммы и разности каких именно чисел нужно считать. Гораздо лучше будет передать эти числа нашему имени в качестве параметров, как мы обычно делаем при вызове команды:

Результат = ПроизведениеСуммыИРазности(А, Б);

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

Давайте, наконец, определим нашу функцию, чтобы компьютер, встретив её вызов, не растерялся, а выполнил то, что мы хотим:

Функция ПроизведениеСуммыИРазности(А, Б)
    Результат = (А + Б) * (А - Б);
    Возврат Результат;
КонецФункции

Что включает в себя определение этой функции?

Прежде всего ключевое слово Функция следом за которым идёт имя, которое мы придумали сами.

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

Дальше идёт тело. Это команды компьютеру, которые будут выполняться в тот момент, когда мы сделаем вызов нашей функции. Тело заканчивается ключевым словом КонецФункции.

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

Возврат Результат;

Где вместо Результат может быть любое выражение, которое вернётся из функции в качестве её результата.

Мы можем вызывать функцию столько раз в программе сколько нам потребуется.

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

Но функции и процедуры не следует писать лишь бы где! Для определения наших функций мы будем использовать новый модуль. Чтобы его добавить следуйте инструкциям ниже.

1. Раскройте список «Общие» в дереве конфигурации.

2. Найдите в нём пункт «Общие модули» и нажмите на нём правой кнопкой мыши. Выберите «Добавить».

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

 Внимание! Пожалуйста, ещё раз убедитесь, что вы поставили галки (Клиент, Сервер, Внешнее соединение) также, как на рисунке выше. 

4. Перейдите в этот модуль. Всё! Здесь можно писать наши функции и процедуры. Напишите процедуру с именем Привет, без параметров, после вызова которой компьютер просто здоровается с нами.

Обратите внимание на ключевое слово Экспорт, которое идёт следом за круглыми скобками. Его наличие обязательно, так как мы определяем функцию в одном модуле (Уроки), а использовать будем совсем в другом (модуль управляемого приложения).

5. Теперь вернитесь в модуль управляемого приложения.

6. И сделайте вызов нашей процедуры. Так как она находится в другом модуле к её имени добавляется «Уроки.«.

7. Запустите 1С и убедитесь, что всё работает!

Пройдите тестирование

Как написать стандартную рабочую процедуру

Много лет назад мне дали задание написать рабочий документ на уроке английского языка в колледже. Учитель объяснил, что нам нужно описать процесс или навык, которые другие могут не знать, как выполнять. Я решил написать о программировании простого четырехтактного паттерна в драм-машине Roland TR-505, используя ясные объяснения и пошаговые процедуры.

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

Неправильно.

Я быстро понял, что написание документа СОП — это больше, чем написание простого процесса.

Пример блок-схемы СОП (Щелкните изображение, чтобы изменить в Интернете)

В чем разница между процессом и стандартной рабочей процедурой?

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

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

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

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

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

Например, вам может потребоваться создать СОП для людей, которые создают примечания к выпуску.СОП может включать:

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

Как написать стандартную рабочую процедуру?

Независимо от того, каким бизнесом вы занимаетесь, у вас должны быть четко определенные СОП-документы, которые помогут вашим сотрудникам понять, как выполнять рутинную работу безопасно, в соответствии с правилами и последовательно, независимо от того, кто выполняет задачу.

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

Шаг 1. Начните с конца

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

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

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

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

Когда вы знаете, чего хотите, чтобы ваша СОП выполняла, гораздо проще написать план и определить детали.

Шаг 2. Выберите формат

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

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

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

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

Схема процедуры (щелкните изображение, чтобы изменить в Интернете)
Блок-схема отбора и обработки потенциальных клиентов (щелкните изображение, чтобы изменить его в Интернете)

Шаг 3. Запросите данные

Соберите команду и спросите их, как, по их мнению, должна выполняться работа.Это люди, которых вы собираетесь попросить соблюдать СОП, поэтому вы хотите быть уверены, что они имеют смысл и что все необходимые задачи включены.

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

Шаг 4: Определите область действия

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

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

Шаблон бизнес-процесса (щелкните изображение, чтобы изменить его в Интернете)

Шаг 5. Определите свою аудиторию

Знание своей аудитории поможет вам определить, как вам следует написать свой СОП-документ.Рассмотрим эти вопросы:

• Каковы их предварительные знания? Знакомы ли они уже с организацией и процедурами? Они уже знают терминологию? Они успокоились и нуждаются в переподготовке? Вам нужно писать на уровне знаний вашей аудитории — слишком упрощайте или усложняйте, и вы потеряете их.
• Каковы их языковые навыки? Может быть, ваша аудитория не говорит на вашем родном языке. Если это так, вы можете использовать больше изображений, чем слов.
• они новые сотрудников? При приеме новых сотрудников ваши СОП-документы должны быть очень подробными и ориентированными на обучение. Вы хотите обеспечить стабильные результаты независимо от того, кто выполняет задачу.
• Каков размер вашей аудитории? Будут ли читать документ несколько человек с разными ролями в разных организациях? Если да, вы можете написать процедуры таким образом, чтобы четко определить, кто или какая роль выполняет каждую задачу.Это поможет вашей аудитории понять, где каждый из них вписывается в процесс и почему важна их конкретная роль.

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

Роли и обязанности (Щелкните изображение, чтобы изменить в Интернете)

Шаг 6: Напишите СОП

Напишите черновик своей стандартной производственной процедуры и рассмотрите возможность включения некоторых из следующих элементов:

Титульный лист

Эта страница может включать:

• Название процедуры
• Идентификационный номер СОП
• Дата публикации или дата редакции
• Название роли, организации, подразделения или агентства, к которому применяется СОП.
• Имена и подписи тех, кто подготовил и утвердил процедуры, изложенные в СОП

Содержание

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

Особые процедуры

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

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

Шаг 7. Просмотрите, проверьте, отредактируйте, повторите

После того, как вы напишете документ стандартной рабочей процедуры:

1. Отправьте проект СОП членам группы на рассмотрение. Попросите их отметить грамматические и технические ошибки.
2. Протестируйте документ самостоятельно, чтобы убедиться, что вы достигли желаемого результата.
3. Попросите других членов группы протестировать процедуры, чтобы убедиться, что язык понятен, легко выполняется и может быть успешно завершен.
4. Внесите соответствующие правки и предложения по улучшению документа.
5. Повторяйте эти шаги, пока документ не будет одобрен и принят всеми заинтересованными сторонами.
6. Внедрить СОП. Сделайте его легко доступным для тех, кому он нужен для работы.

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

Как Lucidchart может помочь вам написать стандартные рабочие процедуры?

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

Начните работу с бесплатной учетной записью Lucidchart сегодня.

.

Как писать политики и процедуры

Написание политик и процедур

Теперь доступна новая версия « Как написать руководство по политикам и процедурам ».

Как написать руководство по политикам и процедурам содержит советы по написанию процедур и сопутствующую информацию. Это полезно для любого человека или проекта, ориентированного на разработку хорошо написанных, удобных для пользователя стандартных операционных процедур ( SOP ), сочетающих в себе политики и процедуры.Написанное опытным разработчиком процедур Крисом Андерсоном из Bizmanualz, это руководство необходимо прочитать всем, кто хочет начать писать или пересматривать свои политики и инструкции по процедурам.

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

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

Процедура написания политик охватывает следующие темы

• Научитесь писать политики и процедуры

  • В чем разница между политиками и процедурами
  • Семь С, чтобы избежать ошибок при написании процедур
  • Как начать писать политики и процедуры
  • Как написать процедуры для усиления контроля
  • Написание процедур для результатов
  • Кто такие процедуры, написанные для
  • Как стимулировать использование процедур
  • Обязательства руководства: ключ к использованию процедур
  • Общение и обращение к вашей аудитории
  • Как организовать свои мысли с помощью карты процессов
  • Формат стандартных рабочих процедур
  • Авторизация, производство и распространение СОП
  • Пересмотр и обновление политик и процедур

  Кроме того, Как написать руководство по политикам и процедурам provi des полезные советы и информация для разработки любых политик и процедур.Это руководство по написанию процедур включает в себя образец процедуры ITSW102 по управлению ИТ-проектами из Руководства по компьютерам и ИТ-процедурам, а также объясняет, как писать длинные описания должностей с Образцами должностных инструкций для финансового директора и технического писателя.

  Написание политик Процедуры Содержание

  Электронная книга в формате PDF

  ВВЕДЕНИЕ

  Что такое процедура?

  ГЛАВА 1 Построение эффективной системы управления с помощью процедур

  Оценка успеха в бизнесе

  Пять этапов построения эффективной системы управления

  ГЛАВА 2 Стандартные операционные процедуры (СОП)

  Стандартные процедуры

  Рабочие инструкции

  Пирамида документации

  Необходимые политики и процедуры

  Почему люди не соблюдают процедуры

  Почему политики не имеют исковой силы

  ГЛАВА 3 Идентификация ваших процессов

  Процессы и процедуры

  Типы процессов

  Основные потоки процессов

  Десять основных бизнес-процессов

  ГЛАВА 4 Отображение процессов

  Понимание карт процессов

  Типы карт процессов

  PDCA

  Отображение процессов

  ГЛАВА 5 Превращение ваших процессов в процедуры

  Форматирование ваших процедур

  Работа с Microsoft Word

  ГЛАВА 6 Написание и проверка ваших политик

  Процесс проверки политик

  Исправление неверных политик

  Написание политик с нуля

  ГЛАВА 7 Написание процедур

  Общение и обращение к вашей аудитории

  Организуйте свои мысли

  Рассмотрение и утверждение процедур

  ГЛАВА 8 Создание ваших политик и инструкций по процедурам

  Для чего нужно руководство по политикам и процедурам?

  Определение формата вашего руководства

  Организация руководства

  Пересмотр и обновление политик / процедур

  ГЛАВА 9 Автоматизация ваших политик и процедур

  Контроль ваших процедур

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

  Word Template Процедура бесплатного образца

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

.

Как написать процедуры для результатов

Итак, вам было поручено написать процедуру… но с чего начать?

Процедуры записи результатов

Мне нравится разбивать процесс на четыре части: Discovery , Design , Development и Deployment . Теперь давайте посмотрим, как писать процедуры для результатов и как они применяются к разным пользователям процедур.

Обнаружение процедуры

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

Разработка процедуры собрания

Plan-Do-Check-Act (PDCA)

Мы используем PDCA (от «plan-do-check-act») для проверки процесса. Один из критериев обзора — убедиться, что процесс соответствует структуре PDCA или процессуальному подходу . В хорошей процедуре ISO 9001 будет использоваться процессный подход для постоянного улучшения.Пример процедуры встречи состоит всего из трех шагов. Организовать собрание (план), провести собрание (выполнить), обзорное собрание (проверка / действие) и выходные данные CAPA (корректирующие действия / предупреждающие действия) представляют собой часть закона.

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

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

1. Кто такие поставщики и что они поставляют в процесс?
2. Что такое входов и в какие выходы они преобразованы?
3. Кто такие клиентов и что они получают от процесса?
4. Кто такие клиенты клиента и что клиент им предоставляет?
5. Каковы критерии эффективности или как мы узнаем, правильно ли работает процесс?
6. Какое корректирующее действие предпринимается, если процесс работает некорректно?

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

Разработка процедуры

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

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

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

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

Доступен новый выпуск «Как написать руководство по политикам и процедурам».

3 типа процедур Пользователи

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

1. Процедуры для постоянных пользователей

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

2. Процедуры для случайных пользователей

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

3. Процедуры для новичков

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

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

Готово? Пока нет, вам нужно выполнить проверку письменной процедуры. Вы можете использовать семь C для просмотра и проверки процедуры для Контекст, Согласованность, Полнота, Контроль, Соответствие, Корректность, и Ясность . После просмотра документа вы готовы приступить к выполнению процедуры в полевых условиях.

Развертывание и аудит процедур

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

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

Для кого написаны процедуры?

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

Еще статьи от Bizmanualz …

.

Руководство по написанию шаблонов политик и процедур

Итак, вам было поручено написать политики и процедуры, и теперь вы ищете шаблоны, которые могут облегчить вашу работу. Шаблоны политик и процедур — это редактируемые документы, которые служат отправной точкой.

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

Доступен новый выпуск «Как написать руководство по политикам и процедурам».

Формат шаблонов политик и процедур

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

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

Примеры шаблонов политик и процедур

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

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

Шаблоны политик и процедур

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

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

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

• План
• Запись / форматирование
• Реализация
• Связь / распространение
• Пересмотр

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

Это 46-страничное руководство по политикам и процедурам при цене 19,99 доллара является отличной ценой. Подготовлено только для электронного распространения, оно доступно для мгновенной загрузки в виде файла PDF. Итак, думаете ли вы о написании процедур или находитесь в процессе разработки политик и процедур, мы думаем, что вы найдете это руководство бесценным ресурсом.

Еще статьи от Bizmanualz …

.