Как описать процесс. Бизнес-процессы: примеры и описание

Владимир Репин

Генеральный директор ООО «Владимир Репин Менеджмент»

Член ABPMP Russia

Консультант по управлению

Бизнес-тренер

Кандидат технических наук

В статье рассмотрены вопросы выбора нотации для описания процессов с целью последующей регламентации. Сравниваются между собой часто используемые нотации Work Flow, такие как: «Простая блок-схема » в MS Visio, «Процедура» Business Studio, нотация ARIS eEPC и другие. При сравнении нотаций основное внимание уделяется вопросам создания простых и понятных сотрудникам организации схем процессов.

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

Введение

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

Сравнение нотаций

Для сравнения были выбраны следующие нотации описания процессов:

1. «Простая блок-схема » (с отображением движения документов, с использованием блока «Решение»);
2. «Простая блока-схема » (без отображения движения документов, без использования блоков «Решение»);
3. «Процедура» системы Business Studio (один из возможных вариантов представления);
4. ARIS eEPC.

В качестве тестового примера был выбран простой и интуитивно понятный процесс. Результаты описания этого процесса представлены на Рис. 1-4.

Рис. 1. Схема процесса в нотации «Простая блок-схема » в MS Visio (с движением документов, с использованием блока «Решение»)

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

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

Сформулируем «плюсы» и «минусы» рассмотренного выше (Рис. 1) способа использования «ромбиков».

«Простая блок-схема » в MS Visio (с движением документов, с использованием блока «Решение»)

На Рис. 2 показан пример того же самого процесса, только описанного без использования блоков «Решение» и документов. Легко проверить, что на этой схеме на 24 графических элемента меньше, чем на схеме Рис. 1. Схема Рис. 2 выглядит гораздо проще. От графических элементов не рябит в глазах, а с точки зрения информативности эта схема вполне понятна и доступна конечному пользователю. Если для каждой операции процесса описать требования к ее выполнению текстом, то комбинируя табличную и графическую формы представления, можно вполне адекватно описать порядок исполнения процесса для сотрудников компании.

Рис. 2. Схема процесса в нотации «Простая блок-схема » в MS Visio (без движения документов, без использования блока «Решение»)

«Плюсы» и «минусы» графического представления процесса в форме, представленной на Рис. 2, показаны ниже.

«Простая блок-схема » в MS Visio (без движения документов, без использования блока «Решение»)

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

На Рис. 3 представлена схема процесса, сформированная в нотации «Процедура» среды моделирования Business Studio. Схема имеет несколько особенностей. Во-первых, блоки «Решение» использованы нестандартным образом — не как графический элемент для отображения вопроса и ветвления, а как полноценная операция процесса, связанная с принятием решений. В Business Studio «ромбик» обладает почти всеми атрибутами полноценного процесса, но не может быть декомпозирован (возможно, разработчики системы со временем сделают такую возможность). Использование «ромбика» (вместо четырехугольника) делает схему нагляднее. При этом в атрибуты «ромбика» можно внести любую текстовую информацию: описание, начало, завершение, требование к срокам и т. п.

Второй особенностью схемы процесса, представленной на Рис. 3, является применение стрелок. Для отображения последовательности операций можно использовать стрелку с одним наконечником — стрелку «предшествования». Для отображения движения документов можно использовать стрелку с двумя наконечниками. Однако в Business Studio можно обойтись использованием только одного типа стрелок — стрелками «предшествования». При этом к именованным стрелкам можно привязывать необходимое количество документов, которые определены в справочнике объектов деятельности.

Такой подход дает возможность:

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

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

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

Рис. 3. «Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»)

«Плюсы» и «минусы» графического представления процесса в форме, представленной на Рис. 3, показаны ниже.

«Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»)

В случае применения Business Studio, нотация «Процедура» может быть использована несколько по-разному. Автор статьи склоняется к подходу, представленному на Рис. 3.

На Рис. 4 представлена схема рассматриваемого процесса, разработанная в нотации ARIS eEPC. Заметим, что на схему не поместились некоторые операции процесса. Эта неполная схема простейшего процесса, выполненная в нотации ARIS eEPC, содержит четыре оператора логики и восемь событий! Сотрудник, читающий схему, должен уметь правильно интерпретировать все эти логические операторы. Без специального обучения и наличия некоторых навыков чтения подобных схем, рядовой сотрудник вряд ли сможет понять логику рассматриваемого процесса без подробного текстового описания или помощи квалифицированного бизнес-аналитика.

Заметим, что схема процесса в нотации ARIS eEPC занимает существенно больше места, чем схемы, представленные на Рис. 1-3. Трудоемкость формирования такой схемы также существенно выше.

Рис. 4. Схема процесса в нотации ARIS eEPC (построена в Business Studio)

Схема процесса в нотации ARIS eEPC (построена в Business Studio)

В целом, если Вы не собираетесь покупать SAP R/3, то выбор и использование нотации ARIS eEPC не является, с точки зрения автора статьи, оптимальным решением. Стоит обратить внимание на более наглядные и интуитивно понятные исполнителям нотации описания процессов. Впрочем, кому-то нотация ARIS eEPC может показаться более наглядной и понятной. До определенной степени, это вопрос вкуса.

Описание процесса для целей последующей автоматизации

Интересно рассмотреть приведенный выше пример описания бизнес-процесса в случае, если он представлен в нотации BPMN 2.0. Это нотация предназначена для описания «исполняемых» процессов, т. е. процессов которые поддерживает система BPM.

Своим мнением об использовании BPMN 2.0. делится А. А. Белайчук — Генеральный директор компании «Бизнес-консоль»:

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

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

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

Рис. 5. Схема процесса в нотации BPMN 2.0

Практика жизни

На Рис. 6 показан фрагмент схемы процесса, разработанный бизнес-аналитиками вполне конкретной компании в придуманной ими нотации. Схема построена с применением принципов «Простой блок-схемы » — применяется блок «Решение» в своем классическом варианте. Кроме этого, на схеме представлено множество других условных обозначений, использованных не совсем стандартным образом.

Рис. 6. Примеры схемы процесса одной из компаний

При формировании схемы Рис. 6, бизнес-аналитики очевидно, «боролись» за наглядность и максимальную понятность для рядового пользователя. Они стремились свести к минимуму, или вообще отказаться от текстового комментария к схемам процессов. Исполнителям просто печаталась схема формата А3, при чтении которой все сразу становилось понятно: что делать, как, какие документы использовать и т. п.

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

Выводы

Итак, очевидно, что при описании процессов нужно стремиться к простоте и понятности для сотрудников.

Использование сложных, формализованных нотаций при описании процессов приводит к:

• Трудностям при использовании (интерпретации) схем рядовыми сотрудниками;
• Невозможности (сложности) организации работ по описанию процессов силами сотрудников подразделений, не прошедших специальное обучение;
• Значительному увеличению трудозатрат бизнес-аналитиков на формирование схем;
• Дополнительным сложностям при документировании схем (большой объем и т. п.).

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

http://finexpert.ru/ — среда общения профессионалов http://bpm3.ru/ — процессы, проекты, эффективность

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

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

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

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

Каждый бизнес-процесс имеет:

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

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

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

Наличие проработанной системы бизнес-процессов значительно упрощает приведение деятельности компании на соответствие требованиям стандартам качества ISO 9001:2015 . В условиях свершившегося вступления России в ВТО, соответствие предприятия стандартам ISO 9001:2015 становится важным конкурентным преимуществом.

Внедрение СМК на предприятии в обязательном порядке требует создания и описания бизнес-процессов.

Разработка бизнес-процессов

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

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

В описании бизнес-процесса можно выделить следующие разделы:

• Стандартные формы бизнес-процесса
• Карта бизнес-процесса
• Маршруты бизнес-процесса
• Матрицы бизнес-процесса
• Блок-схемы бизнес-процесса
• Описание стыков бизнес-процесса
• Вспомогательные описания бизнес-процесса
• Развернутое описание бизнес-процесса
• Документирование бизнес-процесса
• Определение показателей и индикаторов бизнес-процесса
• Регламент выполнения бизнес-процесса

Рассмотрим подробнее каждый этап.

1.Стандартные формы описания бизнес-процесса

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

2.Карта бизнес-процесса

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

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

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

При составлении карты бизнес-процесса следует воспользоваться популярной вопросной формулой 5W1H. Коротко, это 5 вопросов W:

• Who?(Кто совершает данную операцию?)
  
• Why? (Почему или зачем выполняется эта операция?)
  
• What? (Что представляет собой эта операция?)
  
• When? (Когда нужно проводить данную операцию?)
  
• Where? (Где производится операция?)
  

и один вопрос H

• How? (Как совершается эта операция? Можно ли сделать это иначе или внести улучшения?).

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

3. Маршруты бизнес-процесса

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

4. Матрицы бизнес-процесса

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

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

5. Составление блок-схемы бизнес-процесса

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

• Сопоставима ли ценность от данного бизнес-процесса с затратами на его проведение?
• Насколько он интегрирован с другими бизнес-процессами?
• Могут ли быть сразу обнаружены ошибки этого бизнес-процесса?
• Что сделано для улучшения и обеспечения качества этого бизнес-процесса?

6. Описание стыков бизнес-процессов

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

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

Затем составьте аналогичное описание входов.

7. Вспомогательные описания бизнес-процессов

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

8. Развернутое описание бизнес-процессов

Развернутое описание бизнес-процесса может быть в любой удобной для предприятия форме, но должно содержать основные положения:

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

9. Документирование бизнес-процесса

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

10. Определение показателей и индикаторов бизнес-процесса

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

• качество;
• время выполнения;
• количество;
• издержки.

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

Группа индикаторов бизнес-процесса показывает степень достижения цели.

Группа требований включает в себя:

• человеческие ресурсы;
• инфраструктура;
• условия производственной среды.

Группа обеспечения желаемого протекания процесса:

• информация;
• инструкции по выполнению работ;
• время.

• финансы;
• логистика;
• поставщики;
• партнеры и т.д.

11. Регламент выполнения бизнес-процесса

Крупные бизнес-процессы целесообразно оформлять в виде отдельного документа «Регламента выполнения бизнес-процесса ». Остальные бизнес-процессы могут быть оформлены в виде положений о подразделении и должностных инструкций.

В регламент следует заложить требования, обеспечивающие соответствие циклу Шухарта-Деминга:

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

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

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

Общая информация

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

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

Функциональный подход

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

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

Процессный подход

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

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

Описание бизнес-процессов

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

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

Порядок разработки

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

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

Чему следует уделить внимание?

Следует сконцентрироваться на следующих разделах:

1. Стандартные формы.
2. Карта.
3. Маршруты.
4. Матрицы.
5. Блок-схемы.
6. Описание стыков.
7. Вспомогательные описания.
8. Документирование.
9. Развернутое описание.
10. Определение индикаторов и показателей.
11. Регламент выполнения.

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

О картах замолвим слово

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

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

Матрицы

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

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

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

Для чего применяют блок-схемы?

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

Разрабатывать новый процесс;

Описывать и документировать текущий алгоритм;

Разрабатывать модификации к данному процессу либо исследовать звенья с вероятным возникновением ошибок и сбоев;

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

Разработка последовательности операций

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

Типы алгоритмов

На практике чаще всего применяют следующие виды блок-схем:

Графическая, то есть в основе находятся геометрические символы;

Словесная: составляется с помощью обычных слов того или иного языка;

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

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

Блок-схема устройства: описание

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

Основные элементы, употребляемые при составлении блок-схем

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

Элементы блок-схемы:

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

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

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

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

5. Ввод-вывод данных в общем виде.

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

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

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

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

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

Данные элементы должны быть параллельными линиям внешнего периметра или границам страницы, на которой изображена эта блок-схема;

Направление линии сверху вниз или слева направо считается основным, стрелками оно не обозначается, остальные случаи указания направлений обозначены ими;

Изменение направления данного элемента производится только под углом 90 о.

11. Соединитель. Данный элемент предназначен для указания связи на прерванных линиях потока. Эти символы используются в том случае, если блок-схема программы строится из нескольких частей. Тогда линия потока от одной части должна закончиться «соединителем», а новой части - начаться с данного символа. Внутри такого элемента ставится один и тот же порядковый номер. Графическое изображение «соединителя» - это круг.

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

13. Комментарий - это связь между различными элементами блок-схемы с пояснениями. Упомянутый элемент позволяет включать в себя формулы и прочую информацию.

Построение блок-схем

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

Массивы и построение алгоритмов

Массив представляет собой совокупность однотипной информации, которая хранится в последовательных кластерах памяти и имеет общее имя. Такие ячейки называются "элементами системы". Все кластеры нумеруются по порядку. Такой номер называется "индексом элемента массива". Как составить блок-схему для подобной системы? Рассмотрим пример создания алгоритма для элементарного типа. Простейшая система имеет условно вид строки. Зададим имя для данного массива - «А». Будем считать, что наша система состоит из восьми ячеек (от 1 до 8). Каждый из упомянутых кластеров содержит случайное число, которое называется "элементом массива". Для обращения в конкретной ячейке необходимо указывать имя в (). Рассмотрим пример, в котором блок-схема массива предназначена для заполнения системы случайными числами с последующим выводом информации на экран. Что представляет собой такой алгоритм? Это элементарная система. По сути, она не имеет практического применения, однако удобна для учебного процесса. Рассматриваемая блок-схема (пример построения описан ниже) содержит всего семь основных элементов, соединенных линиями переходов.

Описание последовательности выполнения задачи

1. Первым элементом схемы будет символ «Начало».

2. Вторым блоком - «Процесс», внутри которого вписываем «инициализация random».

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

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

5. В этом блоке «Модификации», согласно вписанной функции, происходит переадресация на следующий элемент.

6. «Вывод» производит отображение информации о новом содержимом массива на мониторе с последующим направлением на предыдущий блок. Далее - на последний элемент.

7. «Конец» работы алгоритма.

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

«Редактор блок-схем»

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

Заключение

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

Ключевые вопросы

Краткая характеристика и показатели хозяйственной и иной деятельности

Блок-схемы технологических процессов

Раздел «Сведения о хозяйственной и иной деятельности» проекта нормативов образования отходов и лимитов на их размещение (далее — ПНООЛР), по сути, является той «печкой», от которой надо «плясать» при разработке ПНООЛР. И если раздел «Расчет и обоснование предлагаемых нормативов образования отходов в среднем за год» — это «сердцевина» ПНООЛР, то анализируемый раздел — самое что ни на есть «ядро», из которого должны появиться и «сердцевина», и все остальные разделы и таблицы.

Не случайно в ранее действовавших Методических указаниях по разработке проектов нормативов образования отходов и лимитов на их размещение, утвержденных Приказом Минприроды России от 11.03.2002 № 115 (далее — МУ-2002), аналогичный раздел назывался «Характеристика производственных процессов как источников образования отходов».

Требования действующих Методических указаний по разработке проектов нормативов образования отходов и лимитов на их размещение, утвержденных Приказом Минприроды России от 05.08.2014 № 349 (далее — Методические указания), недостаточно конкретизированы, что на практике иногда приводит к проблемным ситуациям при согласовании ПНООЛР.

Извлечение
из Методических указаний

[…]
19. В разделе «Сведения о хозяйственной и иной деятельности» ПНООЛР в текстовой форме приводится краткая характеристика и показатели хозяйственной и иной деятельности , в процессе которой образуются отходы .
По каждому структурному подразделению (цеху, участку и другим объектам), информация по которым включена в ПНООЛР, представляются блок-схемы технологических процессов, включающие в виде отдельных блоков:
используемые сырье, материалы, полуфабрикаты, иное ;
производственные операции (без детализации производственных процессов);
производимую продукцию (оказываемые услуги , выполняемые работы );
образующиеся отходы (по происхождению или условиям образования);
, включающие их накопление, использование, обезвреживание, размещение, а также по передаче отходов другим структурным подразделениям или другим хозяйствующим субъектам.
[…]

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

С недавних пор вопросы могут возникать и у служащих органов власти субъектов Российской Федерации, поскольку согласно ст. 6 Федерального закона от 24.06.1998 № 89-ФЗ «Об отходах производства и потребления» (в ред. от 03.07.2016; далее — Федеральный закон № 89-ФЗ) к полномочиям субъектов Российской Федерации в области обращения с отходами отнесено в том числе установление нормативов образования отходов и лимитов на их размещение, порядка их разработки и утверждения применительно к хозяйственной и (или) иной деятельности юридических лиц и индивидуальных предпринимателей (за исключением субъектов малого и среднего предпринимательства), в процессе которой образуются отходы на объектах, подлежащих региональному государственному экологическому надзору .

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

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

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

Попробуем разобраться с этими вопросами.

Краткая характеристика и показатели хозяйственной и иной деятельности

Требования Методических указаний распространяются на хозяйственную деятельность организации. Какая именно деятельность имеется в виду?

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

Существует и более широкое толкование, например: «Хозяйственная деятельность представляет собой деятельность по производству продукции, осуществлению работ и оказанию услуг» .

Таким образом, хозяйственная деятельность — это основная деятельность любой организации (как коммерческой, так и некоммерческой).

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

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

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

Количественные — объем производимой продукции, количество работников, площадь посевов, поголовье скота и т.п.;

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

По источникам формирования (способам получения) выделяют показатели:

Нормативные — нормы расхода сырья, материалов, топлива, энергии, нормы амортизации, цены и др.;

Плановые — данные и сведения из планов экономического и социального развития предприятия, плановые задания подразделениям и т.п.;

Учетные — данные бухгалтерского, статистического, оперативного учета;

Отчетные — данные бухгалтерской, статистической и оперативной отчетности;

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

Поскольку Методические указания не конкретизируют требования к показателям хозяйственной и иной деятельности (какие именно, за какой период), у разработчиков ПНООЛР в этом смысле «развязаны руки» — можно внести в раздел показатели по своему усмотрению.

НА ЗАМЕТКУ

Если мы бросим ретроспективный взгляд на то, как раньше формулировались требования к этому разделу, то обнаружим, что в Методических указаниях по разработке проектов нормативов образования отходов и лимитов на их размещение, утвержденных Приказом Ростехнадзора от 19.10.2007 № 703 (далее — МУ-2007), требований было больше, но они во многом были логичны и более конкретны.
Например, что касается показателей деятельности: «Для видов экономической деятельности, направленной на производство продукции, указывается информация об основных видах сырья, производимой продукции, производственной мощности объектов.
Для видов экономической деятельности, направленной на оказание услуг, указываются виды и объемы оказываемых услуг (объемы перевозимого груза, количество посещений, койко-мест и др.)».
Нам представляется, что эти рекомендации можно взять на вооружение при оформлении раздела ПНООЛР и сейчас (а тем, кто разрабатывает ПНООЛР давно, «не снимать» с вооружения!).

В первую очередь желательно приводить такие показатели, от которых зависит образование отходов :

Объем производимой продукции (среднегодовой или с разбивкой по годам);

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

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

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

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

Количество работающих человек;

Площади помещений (торговые, складские, производственные и др.), территории;

Фактическое количество койко-мест (для гостиниц, общежитий), посадочных мест (для предприятий общественного питания), машиномест (для предприятий автосервиса) и т.п.

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

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

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

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

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

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

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

Итак, разработчик ПНООЛР представил структуру предприятия (с подразделениями), привел показатели деятельности. Далее остается вопрос о краткой характеристике деятельности. Может быть, уже достаточно перечня показателей деятельности? Если следовать букве закона, то зачастую этого может быть достаточно: например, информация о количестве обслуживаемых автомобилей, количестве закупаемого сырья, объеме продукции и т.п. уже кратко характеризует деятельность организации.

Но, конечно, дух закона не будет соблюден. Ведь, характеризуя деятельность предприятия, важно указать все источники образования отходов . А для этого необходимо дать более детальное описание технологических процессов при изготовлении продукции; более детальное описание оказываемых услуг и выполняемых работ (например, для автосервисных предприятий: какие детали/узлы/жидкости заменяются). Но насколько подробно все это должно быть указано? Четких рекомендаций в Методических указаниях нет, и здесь приходится полагаться на здравый смысл и на собственный опыт (получаемый порой методом проб и ошибок).

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

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

Описание применяемого оборудования, используемого сырья и материалов;

Все образующиеся в результате отходы;

Все ли отходы учтены.

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

Но бывает и наоборот — сотрудники государственных органов зачастую оказываются специалистами в определенных областях и, зная вид производства или сферы услуг, сразу понимают, какие отходы могут образоваться. А те из сотрудников, кто рассматривает ПНООЛР, уже достаточно поднаторели в своей области (а многие из них еще и участвовали в выездных проверках). Так что разработчикам ПНООЛР не следует уповать на то, что удастся обмануть государственных служащих, утаить (скрыть) какие-то отходы или указать не те, что реально образуются.

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

Блок-схемы технологических процессов

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

В МУ-2007 это было выражено совершенно четко: «Сведения о производственных процессах как источниках образования отходов представляются в текстовой форме или в виде блок-схем по каждому производственному участку».

То есть раньше разработчики ПНООЛР имели свободу выбора: описывать все процессы — как производственные, так и непроизводственные — в текстовом виде или представить блок-схемы.

А еще раньше, согласно МУ-2002, требования были даже более конкретизированы: «В разделе "Характеристика производственных процессов как источников образования отходов" приводится краткая характеристика технологии производства и технологического оборудования, в процессе использования которых образуются отходы. Сведения представляются в текстовой форме или в виде блок-схем производственных процессов по каждому участку. […] Индивидуальные предприниматели или юридические лица, не имеющие в своей деятельности технологических процессов, блок-схемы не составляют и все сведения приводят в текстовой форме».

То есть в МУ-2002 также была свобода выбора, при этом при отсутствии технологических процессов блок-схемы не требовались .

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

И здесь мы сталкиваемся с тем, что не все разработчики ПНООЛР понимают, что же такое блок-схема. Требования Методических указаний заключаются лишь в том, что в виде отдельных блоков должны быть представлены:

Используемые сырье, материалы, полуфабрикаты, иное;

Производственные операции;

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

Образующиеся отходы;

Операции по обращению с отходами.

При отсутствии других требований каждый из разработчиков ПНООЛР действует кто во что горазд, в меру своего понимания.

Вот, например, какие, с позволения сказать, «блок-схемы» нам встречались в различных ПНООЛР (рис. 1):

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

ОБРАТИТЕ ВНИМАНИЕ

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

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

Согласно статье из словаря с хема — это: «1. Совокупность взаимосвязанных частей какого-н. устройства, прибора, узла […]. 2. Изложение, описание, изображение чего-н. в главных чертах» .

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

В технической и справочной литературе есть и определения понятия «блок-схема» :

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

. «Блок-схема представляет собой графический документ, дающий представление о порядке работы алгоритма» ;

. «Блок-схема — схема, определяющая взаимосвязь блоков» ;

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

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

Что же не так в так называемых «блок-схемах» на рис. 1?

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

В один процесс могут быть вовлечены несколько видов сырья/материалов;

С одним видом сырья/материалов могут быть осуществлены (последовательно или параллельно) несколько видов операций;

Один вид отхода в одном производственном процессе может быть образован при осуществлении разных производственных операций;

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

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

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

И если для некоторых процессов такая «линейная» схема (как на рис. 1в) может подойти, то как систему ее рекомендовать нельзя.

КСТАТИ

В МУ-2007 кроме рекомендаций по представлению блок-схем были и требования к составлению таблиц, аналогичных показанным на рис. 1 . Вероятно, разработчики ПНООЛР еще не успели «перестроиться» и вместо блок-схем по-прежнему ваяют таблицы.
Правда, возможно, кого-то отпугивает сложность «рисования» блок-схем, ведь таблицы средствами текстовых редакторов делать легче. Но на самом деле это все вопрос времени и опыта, надо только понять принципы.
Для составления блок-схем подойдут встроенные графические средства текстовых редакторов. Можно использовать графические редакторы или специальные программные средства для создания блок-схем. В конце концов, можно нарисовать (начертить) блок-схемы от руки и отсканировать.

Итак, отметим очевидные ошибки в блок-схемах на рис. 1:

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

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

Так, в примере на рис. 1б для того, чтобы образовался отход «Растворы буровые при бурении нефтяных скважин отработанные малоопасные», очевидно, были применены буровые растворы (которые, в свою очередь, могут быть получены в результате смешивания нескольких компонентов). В примере на рис. 1в мусор от офисных и бытовых помещений — отход потребления, образованный из использованных материалов, а также пыли и, возможно, песка;

Если в результате одного процесса образуется несколько видов отходов (как в примере на рис. 1б — при проведении сварочных работ), то из блока «Производство сварочных работ» должно быть две стрелки , ведущие, соответственно, к образующимся отходам «Шлак сварочный» и «Остатки и огарки стальных сварочных электродов», которые, в свою очередь, могут накапливаться раздельно друг от друга, что также должно быть отражено на блок-схеме;

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

ОБРАТИТЕ ВНИМАНИЕ

Методические указания были утверждены до изменения терминологии в Федеральном законе № 89-ФЗ, поэтому в них говорится об «использовании» (а не об «утилизации») и отсутствует «обработка отходов». Конечно, все операции по обращению с отходами должны быть указаны в соответствии с требованиями федерального законодательства.

Недоумение может вызвать то, что Методические указания рекомендуют включать в блок-схемы «производственные операции (без детализации производственных процессов)». Как известно всем, кто мало-мальски разбирается в производстве и в экономике предприятия, производственная операция — это часть производственного процесса (а не наоборот!). Авторов Методических указаний, а также всех, кому это интересно, отсылаем к специальной литературе, в которой черным по белому написано, что «производственный процесс [...] распадается на множество элементарных технологических процедур, которые совершаются при изготовлении готового изделия. Эти отдельные процедуры называются операциями» . Поскольку уточнение «без детализации производственных процессов» противоречит здравому смыслу, то оставим это на совести авторов Методических указаний.

Судя по всему, в экологи редко идут специалисты, имеющие образование в области информатики. Иначе не возникали бы такие казусы, как на рис. 1, потому что программистам, например, известен ГОСТ 19.701-90 «ЕСПД. Схемы алгоритмов, программ, данных и систем. Обозначения условные и правила выполнения», в котором даны правила выполнения блок-схем алгоритмов, программ, данных и систем; определены графические символы для изображения каждого конкретного вида данных, способа ввода, видов операций, связей между всеми блоками, т.е. конкретные правила построения блок-схем.

Как мы уже отметили, к сожалению, Методические указания не дают никаких правил построения блок-схем производственных процессов, поэтому для экологов эта задача — говоря словами того же литературного персонажа — «quasi una fantasia» , т.е. каждый разработчик ПНООЛР в меру своей фантазии и опыта сам вправе определять графические символы для изображения видов блоков, связи между блоками и в целом общий вид блок-схем. Ну а кто сказал, что профессия эколога не творческая?!

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

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

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

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

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

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

На рис. 3-5 представлены примеры блок-схем основных технологических процессов на предприятии, осуществляющем изготовление медной и алюминиевой проволоки, токопроводящих жил. На рис. 3 показана блок-схема производственных процессов, на рис. 4 — процессов и операций по обеспечению производства (обслуживанию оборудования), на рис. 5 — процессов вспомогательной деятельности (обеспечение освещения и уборки помещений, работы делопроизводства).

Заключение

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

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

Пользуясь случаем, хотели бы обратиться к представителям органов власти субъектов Российской Федерации, реализующим свои полномочия в области обращения с отходами: коль скоро Федеральный закон № 89-ФЗ наделил вас полномочиями утверждать методические указания по разработке ПНООЛР — пожалуйста, будьте критичны к Методическим указаниям. Конечно, не надо отбрасывать то ценное, что там есть. Но брать оттуда требования и положения, противоречащие законодательству и здравому смыслу, на наш взгляд, не нужно. На страницах «Справочника эколога» не раз высказывались критические замечания к Методическим указаниям и предложения по их улучшению (в т.ч. и автором этих строк), которые, как нам кажется, заслуживают рассмотрения.

А вообще, было бы неплохо организовать что-то вроде «круглого стола» (хотя бы «виртуального»), за которым собрать представителей всех регионов России, чтобы обсудить действующие Методические указания и выработать общие подходы по их улучшению. Это будет на пользу как предприятиям, так и служащим всех уровней и ветвей государственной власти.

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

- Прохоров И.О. Нормативы и годовые нормативы образования отходов, правовая основа методов расчета нормативов // Справочник эколога. 2014. № 7. С. 44-57;

- Прохоров И.О. Выбор метода расчета нормативов образования отходов // Справочник эколога. 2014. № 8. С. 75-84;

- Прохоров И.О. Методы расчета нормативов образования отходов: метод расчета по материально-сырьевому балансу и расчетно-аналитический метод // Справочник эколога. 2014. № 9. С. 93-104;

Савицкая Г.В. Анализ хозяйственной деятельности предприятия: учеб. пособие. Мн.: Новое знание, 2002.

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

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

ВСН 514-89 «Требования к проектированию объектов по производству минеральных удобрений с применением блоков. Технология производства».