Процессная модель, как пошаговая инструкция
Очень часто мне задают вопрос, где и когда на практике может понадобиться процессный подход, и какая от него польза? Об этом я и постараюсь сейчас рассказать.
- Если вы – консультант, я надеюсь, что мои пояснения помогут вам в работе с клиентами.
- Если вы – бизнесмен, понимание того, зачем и когда нужен процессный подход, поможет вам в оценке профессионализма привлеченных специалистов, а также для определения четких требований к их работе.
Процессная модель, как пошаговая инструкция.
Когда вы что-то автоматизируете, оптимизируете или создаете что-то новое, крайне важно понимать, что именно вы делаете, как это будет работать. Общие слова и красивые формулировки могут пригодиться на презентации решения, но никак не в процессе работы. Здесь нужно четкое, однозначное и максимально конкретное понимание – что именно будет происходить, шаг за шагом.
И здесь процессный подход становится оптимальным решением:
- Четко определены рамки – начало работы и нужный результат. Все дальнейшие действия проходят уже в обозначенных пределах и не выходят за них, что помогает сосредоточиться на задаче.
- Простая последовательность действий. Вы прописываете действия «шаг за шагом». Человеческий мозг так устроен, что попытки охватить все и сразу приводят к ошибкам и путанице. Намного проще и удобнее постепенно выстраивать последовательность действий, проверяя каждый из шагов на однозначность решения и выстраивая логические разветвления там, где это необходимо (конструкция типа «если – то – иначе»). Не зря именно так строятся все инструкции – четко, пошагово, однозначно.
Рассмотрим в качестве примера фрагмент процесса продаж:
- Прием звонка от покупателя;
- Сохранение звонка (запроса);
- Создание задачи «обработка запроса» на основе запроса от покупателя;
- Автоматическое создание Сделки на основе обработанного запроса.
Все эти этапы обязательно будут отражены в бизнес-модели процесса продажи в процессе разработки. Таким образом, у вас появляется четкая последовательность действий, которые необходимо каким-то образом внедрить.
Теперь начинается анализ каждого этапа:
- Прием звонка. Его нужно автоматически зафиксировать. в CRM-системе и сохранить запись. При выборе программного обеспечения рассматриваем, какие CRM-системы работают с этой телефонией. Все программные решения, которые не могут быть интегрированы с телефонией, более не рассматриваются.Выбор сужается до перечня тех, что удовлетворяют реализации этого этапа.
- Сохранение звонка. Нужно ли вам хранить записи телефонных разговоров? Предоставляет ли телефония эту возможность? Определяем варианты реализации решения. Добавляем техническое задание для специалиста, который будет настраивать CRM-систему требование: сохранение события – «звонок от клиента» с обязательной ссылкой на запись разговора.
- Создание задачи. Прорабатываем детали:
- Как назначается ответственное лицо – автоматически или руководителем?
- Нужно ли отправлять уведомление, об автоматически созданной задаче, руководителю?
- Какие сведения необходимо получить от покупателя на этапе обработки запроса?
- Как определить, что задача выполнена, и можно открывать сделку?(в некоторых случаях этот этап требует 1-2 действий, например, уточнения наличия товара и повторного звонка клиенту).
В других случаях создается «подпроцесс», т.е. этап детализируется подробно. И прописывается перечень требований по автоматизации к каждому из действий.
4. Создание Сделки. Аналогично:
- После каких выполненных условий Сделка будет создаваться автоматически?
- Какие данные (информационные поля) должны быть в документе Сделка?
Ответы на вопросы позволяют еще больше детализировать требования к выбору и настройке CRM. Конечно же если возможно оптимизация тех или иных действий, то оптимизируем.
И так, этап за этапом, вы подробно продумываете . В результате вы получаете четкое и однозначное решение – как это должно работать и что для этого нужно.
Т.е. в процессе разработки процессной модели и ее детализации вы получаете всю необходимую информацию:
- Что именно необходимо выполнить, чтобы прийти к нужному результату.
- Какие ресурсы вам нужны: компьютерные мощности, другое оборудование (телефоны, сканеры, IP-телефония, кассовые аппараты и т.д.). В том числе, в этот список входят люди – на каких этапах и каким образом будут действовать сотрудники. И какая квалификация исполнителя в каждом случае нужна.
- Какие требования к программной системе для вас важны. Готовый список требований поможет из перечня «возможно подходящих» быстро выбрать одну или несколько, которые действительно подходят. И далее уже определяться на основе цены, предпочтений сотрудников или каких-то дополнительных пожеланий.
- Каким образом программная система (или системы) должны быть настроены. Т.е. вы сможете быстро и четко описать техническому специалисту, какие документы и справочники необходимы, какие в них должны быть поля для заполнения, какие задачи в какой последовательности должны формироваться и т.д.
Таким образом, процессная модель, по сути, становится основой для всех дальнейших решений.
Процессный подход при составлении плана работы.
Итак, вы составили процессную модель будущей автоматизации или оптимизации какой-то работы. Теперь вы четко понимаете, что именно вы хотите получить, и даже какие ресурсы для этого потребуются.
Но есть еще один плюс. Процессная модель – это уже практически готовый план выполнения работ, так как вы уже четко понимаете, что именно необходимо закупить, внедрить и настроить. И какие сложности предстоят на каждом из этапов.
Благодаря подробно проработанному процессу вы получаете все необходимые данные для разработки плана реализации решения (автоматизации, внедрения программной системы и т.д.). На основе этих сведений вы можете:
- В качестве приглашенного специалиста – составить план работ с указанием сроков и стоимости в общем или для каждого этапа.
- В качестве клиента – четко и однозначно понимать, что именно вам предлагают, как это будет реализовано, какие ресурсы от вас потребуются, и когда ждать результата.
В любом случае, согласованная процессная модель становится основой для взаимопонимания между заказчиком и подрядчиком. Заказчик понимает, что он получит, и будет принимать работу, основываясь на согласованном решении. Подрядчик четко знает, каким должен быть результат. Никаких разночтений и вольных трактовок. Все четко и однозначно. Об этом стоит поговорить подробнее.
Процессное моделирование для взаимодействия с заказчиком.
Процессное моделирование – это один из самых наглядных и однозначных вариантов объяснить заказчику суть вашего предложения. И не важно, хотите вы при этом продать программную систему или обосновываете оптимизацию работы компании как бизнес-консультант.
Впоследствии заказчик, ориентируясь на нотацию бизнес-процесса, будет принимать работу. Для этого достаточно сравнить результат и заявленную в согласованной модели последовательность действий.
Нередко для подобных целей используют другие варианты:
- Объемные коммерческие предложения, где текстом описываются возможные преимущества. Обычно в них много слов и очень мало конкретных решений. В итоге, заказчик просто не понимает, что и зачем ему хотят продать.
- Технические задания. Иногда составляются заказчиком (особенно часто в крупных компаниях), иногда – подрядчиком после устного обсуждения задачи. Содержат большой объем сложной терминологии, перечень ГОСТов, других технических требований. И множество другой информации, которая, на самом деле, не нужна ни заказчику, ни подрядчику (специалисту по внедрению, бизнес-консультанту и т.д.). Понять суть проблемы или предлагаемые решения на основе таких документов крайне затруднительно.
- Устные переговоры и демонстрация возможностей системы. Подходят для внедрения небольших программных систем, но в сложных случаях почти всегда такой вариант оканчивается неоправданными ожиданиями заказчика и неверным пониманием задачи подрядчиком.
Процессное моделирование — позволяет четко определить поставленную задачу и обозначить результат. Вероятность проблем взаимопонимания снижается до минимума, так как графическая нотация – это просто, понятно, наглядно и однозначно. При этом заказчик четко понимает, что он получит в качестве решения поставленной задачи. И сможет легко проконтролировать полученный результат.
Как это происходит:
- Постановка задачи. Заказчик сообщает о проблеме и о том, что он хотел бы получить.
- В BPMN создается графическая процессная нотация, которая проходит согласование. На этом этапе заказчик понимает, что он получит, и согласен с выбранным решением, исполнитель – что именно нужно сделать.
- На основе согласованного решения выполняется выбор программного обеспечения (с учетом иерархии систем, о которой я уже писал в прошлых статьях).
- Формируется план выполнения работ.
- Выполняется внедрение.
- Заказчик на основе согласованной процессной модели оценивает результат.
Если все действия были выполнены правильно, то в итоге система (подразделение компании или бизнес в целом) работает так, как было оговорено на этапе согласования процессной модели. Результат соответствует ожиданиям. Сотрудничество завершается успешно.
Два уровня: графика и текст
Напоследок поделюсь собственным выводом.
Процессная графическая модель – это действительно удобно, как для себя, в процессе поиска решения, так и для взаимодействия с заказчиком. Но в последнем случае этого мало.
Поэтому лучше сочетать:
- Графическую нотацию(она позволяет понять, что именно получит заказчик. Причем, показывает решение максимально наглядно).
- Текстовое описание(здесь следует подробно объяснить, каким образом будет реализовано решение. Текстом можно подробно описать все важные этапы самой процессной модели, здесь же перечисляется необходимое оборудование и программное обеспечение. В текстовом виде предоставляется и план выполнения работ).
Т.е. графика позволяет понять, что именно получит заказчик, а текст поясняет, как это будет реализовано.
Источник: Блог компании Системный интегратор Тринион
Этапы построения процессной модели.
Предлагаемая
методика применяется на достаточно
успешных предприятиях, достаточно
внимательна к существующему опыту,
старается его сохранить и систематизировать.
(Существует и более радикальный «нулевой»
вариант методики, когда система процессов
фактически строится заново. Он может
быть применен для тех предприятий ,
которые нуждаются в серьезной перестройке
бизнесов, очистке от старой неэффективной
деятельности и ее носителей)
1.Процедура описания начинается с подготовительного этапа: анализа и фиксации существующей организационной структуры предприятия.
Термин
«организационная структура» сразу же
вызывает в нашем воображении двумерную
древовидную схему, состоящую из
прямоугольников и соединяющих их линий.
Относительное положение прямоугольников
и соединяющие их линии показывают
степень
подчинения,
относительное расположение которых
показывает уровень
полномочий.
Сами прямоугольники показывают
выполняемую
работу и круг обязанностей
и, таким образом, отображают разделение
труда в организации. Такое описание
существовало на большинстве советских
предприятий, особенно крупных, которые
могли позволить себе полную
департаментализацию функций: звено или
человек = функция! (То есть, если на
предприятии была функция «вывоз мусора»,
то соответственно существует должность
«специалист по вывозу мусора»).
Многочисленные перестройки предприятия
за прошедшее десятилетие привели к
сокращению персонала и связанному с
этим перераспределением функций – в
результате чего схема «звено или человек
= функция» перестала работать. Также
появились и новые «диффузные» функции,
характерные не просто для рыночной
экономики, а для сетевой экономики
постиндустриального общества. Функции
«диффузных» процессов, распределены
по всему предприятию, а не сосредоточены
в специализированных организационных
единицах, а также могут быть связанными
с функциями основного процесса «жизненного
цикла продукции» пронизывающими все
предприятие по горизонтали. Все это
привело к тому, что существовавшая ранее
традиционная кадровая документация
(должностные инструкции) почти полностью
перестала отражать действительность.
(В «новых» русских компаниях этой
документации не было изначально).
Документированные процедуры (которые
оговорены стандартом ИСО) имеются в
лучшем случае для технологических
производственных процессов. Поэтому
главной задачей первого этапа является
восстановление документированности
деятельности предприятия в традиционном
формате – «кто–что?». Первое, с чем
придется столкнуться даже на самом «у
спешном» предприятии, это полная
неопределенность с документами
регламентирующими бизнес – в лучшем
случае это пожелтевший листок с
квадратиками («структурная схема»),
штатное расписание, телефонный справочник
или, все те же, «запыленные» должностные
инструкции, представляющие интерес для
историков фабрик и заводов. Тем не менее,
любые сведения о компании надо тщательно
собрать, сгруппировать функции по
подразделениям и занести это в orgware.
Анализ документов целесообразно
дополнить данными, полученными путем
анкетирования персонала компании.
Причем желательно провести опрос на
двух уровнях: топ-менеджеров, отвечающих
за функциональные направления или
отдельные бизнесы («какие функции, по
их мнению, выполняют подразделения»),
а также сотрудников этих подразделений
(«что, они делают на самом деле»). В
итоге получатся три
первичных модели компании: «по документам»,
«взгляд сверху» и «взгляд снизу») .
Далее, необходимо устранить , неизбежные
противоречия между этими «тремя моделями»
и сделать признаваемый всеми исполнителями
классификатор «что они делают».
Таким
образом
мы
фактически восстановим (или создадим
там где такого не было) описание
существующей деятельности в форматах
начала ХХ века – впрочем они продержались
и держатся еще до сих пор.
В
результате этого этапа будет получена
начальная модель предприятия совмещающая
дерево организационной структуры и
функции выполняемые сотрудниками
(«служебный» классификатор).
На
реальном примере такого описания можно
оценить уровень точности, который
обычно достигается при использовании
подобного формата (раскрыты две первые
позиции):
2. Теперь можно перейти
к собственно первому этапу перехода к
процессной модели – «идентификация
процессов» предприятия – классификации
функций по компонентам менеджмента,
основным и обеспечивающим бизнес-процессам
.
2.1.
Функции, закрепленные в «служебном»
классификаторе за звеньями, должны быть
проанализированы и перегруппированы
с целью выделения контуров управления
(замкнутых управленческих циклов),
производственно-коммерческих цепочек
и обеспечивающих процессов , существующих
в компании .
В
качестве шаблонов для группировки
зафиксированных в служебном классификаторе
функций рекомендуется использовать
базовые классификаторы, рассмотренные
во втором разделе настоящего документа.
Однородные функции подразделений будут
сведены в группы упорядоченные, по
возможности, как иерархически, так
и по последовательности исполнения.
Но
на каком-то уровне необходимо остановиться
– и перейти от подобного выделения
«процессов» к их детализации на уровне
«операций», назначение и результаты
которых однозначно соответствуют их
названию. Надо также иметь ввиду, что
ряд операций основного цикла (прежде
всего по сбору информации), совершается
в интересах других процессов – прежде
всего процессов управления! В результате
этих операций мы получим, так называемое,
«дерево» процессов компании.
2.2.
Тем не менее после такого описания
большинство процессов, во всяком случае
на документальном уровне, по так
называемой «шкале зрелости» (см.
Приложение
3)
будут находиться на стадии «Неполный
процесс»
– уровень доказательства их систематического
и контролируемого выполнения отсутствует
либо недостаточен. Но теперь для
получением большей точности описания
уже возможен первичный управленческий
анализ полученного «функционала»:
-
полноты
выделения функций. -
полноты
реализации (этапности) выполнения
функций
В
результате дополнительного анализа
происходит частичное восстановление
«неполных» процессов и их первичное
процессное осмысление.
2.3.
Чтобы полученная
картина в наибольшей степени соответствовала
действительности , полученные
классификаторы, необходимо согласовать,
то есть найти на предприятии людей,
компетентных и берущих на себя
ответственность за происходящее в
различных функциональных областях.
При
этом целесообразно
соблюдать определенную последовательность
действий:
На
первом этапе на согласование выдавать
только состав процессов и функций (без
учета того, за кем эти функции закреплены).
Это позволит сосредоточиться на
главной задаче описание функционала
предприятия.
Назначение
ответственных за согласование и
дальнейшее их разделение на ответственных
за описание более мелких фрагментов
лучше всего сделать сверху вниз. На
верхнем уровне (например: Маркетинг и
сбыт, Производство, Логистика, Техническое
обеспечение производства, Информационное
обеспечение, Административное управление,
Финансово-экономическое управление,
Организация учета, Обеспечение и
управление качеством, Обеспечение
безопасности и охрана окружающей среды)
целесообразно, чтобы это сделал
Генеральный директор.
Уже
на первом уровне, если не найти того,
кто считает возможным ответить за всю
группу функций, перед передачей на
согласование их можно разделить. Это
может сделать сам директор. (Например,
из всего административного управления
выделить функции «Обеспечение
документооборота на предприятии»,
«Юридическое обеспечение» и т.п.). То же
самое и по производству, логистике и
т.п. Важно то , что они детализируют
взятый за основу перечень процессов
верхнего уровня и тем самым поддерживается
системность описания предприятия. Далее
назначенные директором ответственные
за согласование выделенных групп
функций, если они не могут согласовать
все по своему разделу самостоятельно
– отдают полномочия тому, кто это может
сделать по относительно более мелким
функциям и т.д.
Интересным
следствием такой методики согласования
является то что, ответственность за
согласование хорошо отражает
ответственность за выполнение этой
функции или процесса на предприятии!
(В ходе работ по согласованию это
желательно не акцентировать, но иметь
ввиду).
2.3.
Пример
согласованной модели Основной
бизнес-цепочки:
Каждый
из подпроцессов может быть раскрыт на
более низких уровнях: Например:
И
так далее:
2.4.
После чего, для всех согласованных
процессов (на
выбранном уровне)
следует попытаться определить его
основное
назначение и результаты (итог) процесса
в следующем формате:
-
Назначение
процесса «ХХХ» является …. -
В
результате реализации процесса «ХХХ»
будет получено …
Если
эта операция вызывает трудности:
например, сложно сформулировать либо
первое, либо второе – необходимо
перенести границу процесса – например,
объединить его с другим по технологической
цепочке.
Пример
фрагмента модели Основной бизнес-цепочки
на уровне: «Выполняемый процесс»:
В
результате этого этапа процессы компании
определены и по «шкале зрелости» –
перешли на уровень «Выполняемый процесс»
– реализуемый процесс достигает явно
идентифицированных результатов.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
Дмитрий Александрович Каштанов
Эксперт по предмету «Управление качеством»
Задать вопрос автору статьи
Определение 1
Процессная модель – это упрощенное представление системы менеджмента качества, в котором выражены ее главные признаки через призму процессов, составляющих деятельность организации.
Основы моделирования процессов
Решение задач по проектированию процессов в организации и повышению их эффективности, т. е. по их оптимизации, совершенствованию приводит к необходимости моделирования. Моделирование представляет собой метод познания, в основе которого лежит аналогия, т. е. отношение частичной эквивалентности между объектом и его моделью.
Как правило, моделью называют систему, которая представлена мысленно или реализована материально, отображает, воспроизводит и замещает некий объект, что дает возможность посредством изучения модели получить новую информацию об этом объекте. В целом, моделирование с точки зрения теории систем является чуть ли не единственным средством для эффективного описания сложных систем.
В течение продолжительного периода времени моделирование процессов рассматривалось как вспомогательная задача, которая решалась при их автоматизации. Да и в настоящее время многие предприятия занимаются моделированием только на этапе предпроектной подготовки при внедрении информационных систем.
Впоследствии конструкция процессов совершенствовалась через создание систем менеджмента качества. Одним из базовых принципов такой системы является требование «непрерывного совершенствования» процессов.
Очевидным фактом является отличие требований к модели как к инструменту подготовки процессов к автоматизации от требований к модели, которая используется при системной организации деятельности, инструмента «организационного управления». По состоянию на сегодняшний день идеология построения моделей деятельности организаций базируется на общем взгляде на нее и ориентирована на достижение более широких целей, чем моделирование лишь выделенных последовательностей действий, которые подлежат автоматизации.
«Построение процессной модели системы менеджмента качества» 👇
Модель системы менеджмента качества должна давать ответы на вопросы, которые поддерживают все существенные аспекты управления организацией. Отсюда следуют вопросы к самой модели и методам ее построения:
- Как выделять процессы в организации?
- Как и какую ответственность закрепить за владельцем процесса?
- Как представить связь процессов со стратегическим уровнем?
- Какой стандарт выбрать для представления модели процессов?
- Как выбрать последовательность построения модели?
Основы построения процессной модели системы менеджмента качества
В большинстве случаев построение процессной модели системы менеджмента качества организации начинается с определения принципов, на основе которых будут выделены процессы. Так, суть современного процессного подхода сводится к тому, чтобы в модели организации были выделены «сквозных» бизнес-процессов и осуществлялось управление этими процессами, которые должны быть направленными на группы клиентов с точно установленными потребностями.
В рамках процессного подхода, который закреплен в современных стандартах, менеджмент организации должен сосредоточиться не на отдельных функциях, а на бизнес-процессах, определяющих суть его деятельности. Причем бизнес-процесс имеет своих рыночных «платежеспособных» заказчиков (получателей), а также, как правило, пересекает организационные границы, т.е. протекает поверх барьеров, которые существуют между структурными подразделениями организации.
Замечание 1
Сутью процессной модели управления является выделение «сквозных процессов» в качестве основного объекта управления и формирование института их владельцев. Такое выделение позволит организации гибко реагировать на получаемую от рынка информацию.
Основанием для процессного подхода также выступает выделение межфункциональных горизонтальных структур, благодаря чему организация может «восстановить разорванные связи» с конкретными потребителями. Благодаря этому будут удовлетворяться постоянно изменяющиеся рыночные потребности и создаваться сильные конкурентные преимущества организации.
Процессная модель системы менеджмента качества чаще всего приобретает вид матричной структуры управления в разрезе двух векторов. Первый вектор представлен функциональными подразделениями, которые выступают в качестве «центров управления ресурсами». Второй вектор представлен реализуемыми «сквозными» процессами, которые используют эти ресурсы.
При построении процессной модели системы менеджмента качества организации ее руководителям нужно еще учитывать разделение всех связанных с процессом видов деятельности на две основные части. Во-первых, выделяют технологию выполнения процесса, которая по сути является способом выполнения деятельности. Во-вторых, выделяют систему менеджмента процесса, которая по сути является способом управления деятельностью.
Мировая практика привела к образованию нескольких стандартов моделирования (описания) процессов в организации. Так, одной из наиболее популярных методологий является методология IDEFO, в основе которой лежат три основных принципа:
- Принцип функциональной декомпозиции – любая функция (т.е. свернутый бизнес-процесс) может быть разбита на более простые действия (процессы), что позволяет изнутри рассмотреть функциональный блок, состоящий из самого процесса, его регламента, исполнителей, оборудования, а также входных и выходных ресурсов и информации.
- Принцип контекстной диаграммы – представление на диаграмме объекта в виде единственного блока, а все потоки подразумеваются приходящими извне или уходящими во вне организации.
- Принцип ограничения сложности – представление информации на диаграмме в концентрированном виде, что требует принятия мер по повышению ее наглядности.
Таким образом, построение процессной модели системы менеджмента качества является в настоящее время одним из основных видов деятельности в области управления качеством.
Находи статьи и создавай свой список литературы по ГОСТу
Поиск по теме
