Бизнес процессы. Теоретическая часть
1.1. Система процессного управления
1.1.1.Возникновение процессного подхода
Если рассматривать человеческую деятельность как процесс, то фактически процессы появились вместе с цивилизацией, а если взять природные процессы, то они существовали всегда.
Первое упоминание о процессном подходе как отдельной области исследования относится к 20 годам прошлого столетия, когда в одной из компаний, где клерки работали с документами, был проведен анализ эффективности работы с использованием процессного подхода. Руководитель решил проанализировать, как часто сидящие в одном большом помещении сотрудники передают друг другу документы. Была составлена схема, отражающая размещение сотрудников в помещении и все возможные взаимодействия между ними. За небольшой промежуток времени была собрана статистика всех взаимодействий. По результатам анализа была проведена простая оптимизация: наиболее часто взаимодействующих между собой сотрудников посадили рядом друг с другом. В результате меньше времени тратилось на передачу документов. Это стало первым известным примером проведения описания и оптимизации процессов в бизнесе
1.1.2.Управление по целям через процессы
Процесс - последовательность исполнения работ (функций, операций), направленных на создание результата, имеющего ценность для потребителя.
Основой любого процесса является целенаправленность, взаимодействие и последовательность.
Целенаправленность - способность процесса достигать определенного результата (цели), обязательный элемент процессного подхода, основной критерий оценки для выбора процессов, показателей эффективности и оценки на их основе всех мероприятий по улучшению. Например, «Процесс продаж» может иметь целью продать, в соответствии с планом, определенный ассортимент продукции по требуемым ценам в необходимом объеме в названных регионах
Взаимодействие (интерфейс) - важная категория, определяющая, насколько соответствует результат, полученный участником процесса, потребностям потребителя этого результата (совсем не обязательно, чтобы он был клиентом организации, это может быть сотрудник соседнего, а иногда и того же отдела).
Последовательность (поток) - представляет собой очередность действий, выполняемых в соответствии со всеми установленными условиями и определяющими направление дальнейшего движения. Правильно выстроенная последовательность позволяет избавиться от ненужных операций, сократить длительность и стоимость процесса, добиться улучшения качества результата
Предприятие в целом можно рассматривать как систему, потребляющую ресурсы на входе, преобразующую их внутри себя и выдающую на выходе товары (работы, услуги). Вся эта система представляет собой процесс, осуществление которого обеспечивает получение результата, позволяющего достичь целей организации. Цель компании (целевая корпоративная установка) в этом случае определяет содержание и форму процессов. Каждый процесс при этом имеет свою цель, которая является критерием эффективности данного процесса - насколько оптимально процесс ведет к ее достижению. Выполнение целей всех процессов приводит к достижению целей компании. 11 Сколько и каких процессов должно быть в компании определяют цели и стратегии их достижения
Количество процессов должно соответствовать поставленным целям по их оптимизации и степени детализации, необходимой для осуществления данного вида деятельности.
Как можно заметить, один процесс может быть средством достижения нескольких целей. С другой стороны, достижению одной цели могут способствовать несколько процессов.
Таким образом, чтобы достичь поставленных целей, компании необходимо управлять своими процессами, организуя их взаимоувязанное исполнение. Это означает, что необходимо создать процессную структуру компании, которая образуется путем «связывания» процессов с целевой структурой. Часто происходит подмена понятий, и вместо процессной структуры используют классификацию процессов, т.е. структуру их типов. Множество подобных классификаций можно найти в литературе, где процессы сгруппированы по какому-либо выбранному признаку. Но это не является процессной структурой, так как не обеспечивает их взаимоувязанности для достижения целей, т.е. того, ради чего, они собственно и предназначены. Чтобы сформировать процессную структуру, необходимо иметь следующее:
• цели компании, которые формируются на этапе разработки стратегии1;
• процессы компании, которые формируются на этапе бизнес-инжиниринга, т.е. их описания и моделирования в целях их последующей оптимизации. Именно второму этапу и посвящено все нижеследующее описание - как работать с отдельным процессом. Научившись делать это с одним процессом, компания затем продолжает описание других процессов, «подвязывая» их на цели, и, таким образом, приходит к реализации процессного подхода управления всей компанией. В рамках такого подхода она оптимизирует процессы достижения своих целей, а значит, повышает свою эффективность
1.1.3. Классификация процессов
По участию в добавлении качества к продукции/услугам процессы можно разделить на две основные группы: основные и вспомогательные
Основные процессы - это процессы, в результате которых создается добавленная стоимость (новое качество). Подобные процессы кроссфункциональны - в их рамках происходит взаимодействие как с клиентами, так и потребителями. К данной категории относятся снабжение, производство, сбыт, логистика.
Вспомогательные процессы - это процессы управления (планирование, учет, анализ); создания инфраструктуры управления и бизнеса (информационного обеспечения, системы качества, производственных систем); процессы разработки новых продуктов и услуг.
Примерный перечень процессов, разработанный Американским центром производительности и качества (см. Приложение 6.1.)
Существуют также и другие взгляды на классификацию процессов. Например, в методологии системы BAAN (BAAN Orgware) выделяется четыре, так называемые, «категории стратегических моделей» в которые входят все процессы компании
1. Модель финансового управления (взгляд на бизнес с точки зрения движения финансовых средств).
2. Маркетинговая модель (оценка влияния внешней среды на рассматриваемый бизнес).
3. Модель управления производством.
4. Модель управления логистикой (снабжение и сбыт) .
Все процессы по методологии BAAN Orgware делятся на основные и детальные.
• Основные процессы (main) - являются специфичными для определенного типа организации и определяются из контрольной модели потока товаров.
• Детальные процессы - имеют общую природу, могут применяться в различных типах организаций.
Методология предлагает следующий перечень детальных (общих) процессов;
MN - Manufacturing - производство;
В А - Basic Data Process -основные данные;
SL - Sales Process - процесс продаж;
PU--Purchasing- закупки;
PL - Planning (all resources) - планирование;
Fl - Finance - финансы;
SE - Service - обслуживание;
WH - Warehousing - хранение на складе;
EN - Engineering - конструирование;
FR - Formula Management - управление формулами;
IT- System Management - управление устройствами;
PI - Project Industries - проектные производства:
PS - Project Services - обслуживание проектов;
PM - Product Batch Management - управление упаковкой продукции;
QI - Quality Inspection - проверка качества:
QM - Quality Management - управление качеством;
Являясь объектом управления, процессы должны быть соответствующим образом выстроены. В большинстве же своем процессы никем не управляются, никто не несет ответственности за конечный результат, процессы не описаны и не документированы.
Для того чтобы работать с процессами, необходимо выяснить следующие моменты:
• из чего они состоят;
• какие существуют средства описания и документирования;
• кого назначать ответственными;
• как анализировать эффективность того или иного процесса.
Тенденция в развитии процессов - "вытягивание" их за пределы организации, т. е. создание кроссорганизационных (межорганизационных) процессов, в том числе, организация процесса электронной коммерции (е-бизнес). Создание и оптимизация межорганизационных процессов направлены па снижение транзакционных издержек предприятия
Транзакционные издержки - финансовые потери, которые несет компания в результате некачественного взаимодействия со своими внешними контрагентами: клиентами, поставщиками, партнерами, представителями государственных органов, иными участниками хозяйственной деятельности
1.1.4. Взаимосвязь процессного и функционального подхода в управлении. Владельцы процессов
Функциональная организация характеризуется постоянными структурами (статическими), такими как оргструктура и функциональная структура. Организация процессов связана с нестабильным (динамическим) поведением процессов, необходимых для выполнения целевой корпоративной установки
Между иерархической организационной структурой и процессами, протекающими в ней, существует тесная взаимосвязь, так как конкретные действия в процессах выполняют сотрудники, находящиеся в различных подразделениях. Связь эта устанавливается через регламентные документы (Положения о службах, о подразделениях и Должностные инструкции), в которых, с одной стороны, определяется состав и распределение функций по подразделениям и сотрудникам, а с другой стороны, - в описании процессов, - устанавливается четкая последовательность действии конкретных сотрудников по выполнению ими своих функциональных обязанностей
При этом в функционально-ориентированной организации не существует ответственных за выполнение кроссорганизационных процессов. В этом случае управление концентрирует свое внимание на различных частях организации. Это приводит к появлению транзакционных издержек. Для решения этой проблемы в процессном управлении выделяются ответственные за процесс - так называемые, владельцы процесса.
Владелец процесса (руководитель процесса) - сотрудник компании, отвечающий за результат функционирования определенного процесса и имеющий полномочия вносить изменения в любую часть «своего» процесса
В целях управления владелец процесса создает себе команду, состоящую из нескольких участников процесса, в совокупности обладающих знаниями обо всех особенностях выполняемых работ/операций. Для внесения новизны и объективного взгляда со стороны на принимаемые решения в команду привлекаются специалисты по информационным технологиям, эксперты и консультанты
Команда на регулярных совещаниях обсуждает эффективность выполняемого процесса, ставит задами по улучшению процесса и контролирует их выполнение. В организационной структуре владелец процесса становиться аналогом проект-менеджера, привлекающего ресурсы функциональных отделов для решения задач общей оптимизации работ в процессе.
1.1.5. Границы и интерфейсы процесса. Клиенты процесса
Большинство крупных процессов, протекающих в организации, начинаются и завершаются далеко за ее пределами. Процесс снабжения берет свое начало в процессах поставщиков по производству и поставкам необходимых ресурсов, процесс продаж продолжается эксплуатацией/потреблением продукции или услуг, т.е. процессами нашего клиента. Чтобы определить, где находятся границы того или иного процесса, необходимо сопоставить цель процесса с возможностями влияния на него в случаях, когда он выходит за пределы организации. Если есть возможность скоординировать процесс с поставщиками /потребителями и влиять на ход процесса за пределами компании, то граница процесса выходит за пределы фирмы. Для определения состояния, приводящего к началу или завершению процесса, используется понятие «события». При выполнении процесса одни действия чередуются с другими. Чередование действий происходит в определенном порядке, который определяется событиями. Например, в процессе «заключение договора» можно выделить несколько событий: форма договора подготовлена, договор согласован, договор заключен, договор расторгнут. Все эти события возникают в результате определенных действий участников процесса Заключение договора. Событие не имеет продолжительности, так как является констатацией свершившегося факта. При определении события в него включают объект, состояние которого описывает событие, и собственно описание самого состояния. Например, «договор заключен». Теперь приведем формальное определение события.
Событие - факт получения информационным объектом (примеры информационных объектов: документ, факс, e-mail и т.п.), связанным с бизнес-процессом, статуса (примеры статусов: получен, отправлен, внесен в базу данных и т.п.), который управляет или воздействует на дальнейшее выполнение бизнес-процесса. События переключают функции, т.е. передают управление от одной функции к другой; они могут быть также результатом выполнения функций. В отличие от функций, которые имеют некоторую продолжительность, события, происходят моментально. Примерами событий могут служить: «Заказ получен», «Факс отправлен», «Товар доставлен». События используются для обозначения начала и завершения действий или процессов. Любой процесс всегда начинается и заканчивается событием.
Границы процесса - события, начинающие и завершающие процесс
Начинающих и завершающих событий у процесса может быть несколько. Например, процесс может начинаться либо с получения заказа, либо с получения рекламации.
С определением границ процесса связано также понятие интерфейса процесса. Каждый процесс использует внешние ресурсы и производит продукты или услуги. Все эти входы и выходы процесса являются интерфейсами (в переводе с англ. - взаимодействие) процесса. Если требования к качеству ресурсов компания предъявляет к поставщикам и добивается их выполнения, то с другой стороны процесса находятся клиенты, которые, в свою очередь, предъявляют требования к результатам деятельности компании. Таким образом, границы устанавливают пределы ответственности за результаты процесса.
Интерфейсы возникают не только на границах процесса. При переходе от одной функции процесса к другой передаются также и ресурсы, и это тоже является интерфейсом. Если обе функции, между которыми располагается интерфейс, принадлежат процессу, значит этот интерфейс внутренний в отличие от внешнего интерфейса, находящегося на границе процесса.
Взаимодействие может осуществляться через документ, информационную систему и т.д. Определение и унификация интерфейсов необходима для слаженной работы процесса. Одной из основных задач управления бизнес-процессом является выявление несоответствий результатов, полученных одной операцией, для выполнения последующей операции. Для решения подобных проблем, разрабатываются форматы интерфейсов, учитывающие требования потребителей к результатам выполнения операции
Клиент процесса - потребитель продуктов/услуг, которые создаются в процессе, и предъявляющий к ним требования.
Работа с процессами является составной частью построения систем обслуживания клиента. Необходимо организовать процесс таким образом, чтобы учитывались все изменения требований клиента для быстрого приспособления процесса к их удовлетворению. Клиенты могут быть не только внешние, но и внутренние. Существует множество процессов, потребителями результатов которых являются другие подразделения одной и той же организации. Такие клиенты могут также предъявлять свои требования к продуктам/услугам. Лишь в этом случае появляется возможность использовать весь потенциал процессного подхода. Процессный подход, таким образом, не делает различий между внешними и внутренними клиентами. Если плохо будет обслужен внутренний клиент, то рано или поздно его неудовлетворенность по цепочке «докатится» до внешнего клиента и проявится в работе с ним. Высокая клиентоориентированность - отличительная черта процессного подхода.
1.1.6. Принципы процессного управления
• Процессное управление основывается на управлении по целям.
• Количество и форма процессов определяется целями.
• Ответственность за результат и выполнение процесса возлагается на владельца процесса.
• Процесс имеет внешние границы и взаимодействует с окружением через интерфейсы (вход - ресурсы, выход - продукты и \ слуги).
• Требования к результатам процесса предъявляют клиенты процесса.
Pasted from <http://www.regcons.ru/5-step-1-1.htm>
Описание бизнес-процессов
Как невозможно в промышленности без чертежа создать изделие, так невозможно без описания проектировать процесс. Описание - это «чертеж» процесса, создав который, вы получаете возможность изменять его в требуемую сторону, а значит, управлять им. Для составления описания бизнес-процесса, в первую очередь, необходимо определить его элементы. Таковыми являются:
• функции (операции, действия);
• события (в некоторых методиках используется термин «состояния»);
• ресурсы, среди которых, отдельно выделяют две группы: о исполнители - роли, сотрудники, должности, подразделения о информационные ресурсы - документы, файлы, архивы и другие носители информации;
• продукты и услуги
1.2.1. Функции (операции, действия)
Функция - сложное понятие, наиболее часто используемое при обозначении границ ответственности сотрудников. Так как функция - набор действий, это позволяет нам рассматривать процесс как частный случай функции. С другой стороны, процесс может включать в себя действия, являющиеся функциями. В данной методике эти понятия рассматриваются совместно. И иногда используются как синонимы. Например, процесс работы с клиентом - последовательность действий, а функция работа с клиентом, закрепленная за отделом продаж - это крут обязанностей. В данном случае эти понятия совпадают.
Функция (формальное определение) - это предметно-ориентированное задание или действие, выполняемое над объектом, в результате которого достигается одна или несколько целей, стоящих перед компанией
Возможны три варианта структурирования функций на предприятии
• по объекту - объектно-ориентированный;
• по процессу - процессно-ориентированный;
• по операциям - операционно-ориентированный
Объектно-ориентированный подход заключается в том, что выделяются все функции, которые воздействуют на один и тот же объект, например, «заказ» (см. Рис. 4). При процессно-ориентированном подходе выделяются все функции, задействованные в процессе, например, «обработка заказа» (см. Рис. 5). При операционно-ориентированной структуре функций внимание сосредотачивается на виде операций, например, «корректировка».
1.2.2. События
Понятие «событие» уже приводилось при описании внешних границ процесса. Оно означает приобретение определенного статуса объектом, связанным с бизнес-процессом. Кроме определения границ процесса, события используются и в самом процессе для обозначения ветвлений (вариантов). Например, при выполнении функции «Проверка наличия товара на складе» может быть два результата: «Товар есть в наличии» либо «Товара нет в наличии». В данном случае это и будет событиями, показывающими направление течения процесса. Если «Товар есть в наличии», то далее может следовать отгрузка. Если «Товара нет в наличии», то клиент) сообщается о невозможности выполнить заказ и просьба перенести его на другой период.
В комплексных информационных системах чаще используется понятие «состояние)). Состояние и событие всегда связаны с каким либо объектом. В случае события «Товар есть на складе» некий объект (товар) находится в состоянии наличия. В дальнейшем описание состояний объектов помогает составлять требования к информационной системе.
1.2.3. Ресурсы
Ресурсы - потребляемые в процессе предметы труда и используемые в процессе средства труда.
В качестве предметов труда в процессе могут выступать сырье, материалы, комплектующие и т.п., а в качестве средств труда - машины, инструменты, оборудование. Также к ресурсам относят труд, информацию, знания и т.д. В данной методике трудовые и информационные ресурсы (в связи с их особыми свойствами) будут рассматриваться отдельно.
1.2.4. Исполнители
Исполнители (участники процесса) - сотрудники, выполняющие в процессе определенные обязанности (действия), включая внешних (не входящих в штат компании, например, консультанты, аудиторы и т.д.). Существуют следующие типы участников процесса:
• организационные звенья - структурные подразделения - отделы, и т. д.;
• должности - различные должности из штатного расписания компании, например: Менеджер по продажам, Логистик, Товаровед, Начальник цеха №1;
• сотрудники - персоналии, работники компании (ФИО), например, Иванов Иван Иванович;
• роли - обособленные группы обязанностей, которые может исполнять сотрудник в процессе, обладая при этом и определенными правами. Роли могут в частном случае совпадать с должностью - как по функционалу, так и по названию. Например: Гл. бухгалтер, Системный администратор.
Организационные звенья могут использоваться при наиболее общем описании бизнес-процессов всего предприятия или для описания функционала организации.
При описании бизнес-процессов рекомендуется использовать должности и роли в качестве исполнителей операций.
Использование ролей практически аналогично должностям. Различие заключается в том, что одна должность может исполнять несколько ролей. Например, в небольшой организации Финансовый директор может исполнять функции и финансиста и гл. бухгалтера. Или программист может являться еще и системным администратором. В этих случаях указывается, что данная должность подразумевает в организации несколько ролей, и в процессах используются обозначения ролей. Кроме этого, при внедрении информационных систем каждый работающий с системой получает определенную роль, характеризующуюся правами доступа:
• Администратор
• Пользователь
• Финансовый директор (в данном случае не должность, а роль в системе, определяющая права на доступ к информации и права использования отчетов и других инструментов).
Необходимость использования тех или иных участников, например, ролей, определяется целями описания бизнес-процесса, а через них - необходимым уровнем детализации. Роли необходимы для описания действий сотрудников на уровне работы с информационной системой, а отделы на уровне анализа распределения функций по организации. При описании бизнес-процессов организации в основном используют должности. Только в крайнем случае используются сотрудники (т.е. ФИО), так как это показывает зависимость выполнения бизнес-процесса от личности исполнителя.
Сотрудники принимают различное участие в процессе. Можно выделить следующие типы участия в процессе.
• Исполняет (executive) - непосредственно участвует в выполнении действия, причем, если есть несколько исполнителей, то подразумевается, что они взаимозаменяемы и каждый может выполнить действие самостоятельно.
• Утверждает результат - обычно руководящие должности.
• Вносит вклад в (contributes to) - непосредственно участвует в исполнении, но, в отличие от исполнения (executive), предполагается обязательное участие всех исполнителей. При отсутствии одного из них функция не выполняется, так как исполнители не взаимозаменяемы. Например, для переноса холодильника нужны два грузчика: оба выполняют одну и ту же функцию, но один не сможет выполнить эту функцию без другого.
• Отвечает за ИТ обеспечение - например, системный администратор.
• Консультирует такой тип связи присутствует при участии внешних консультантов.
• и др.
Каждый вид участия должен правильно отражаться в процессе соответствующим обозначением либо описываться в примечаниях к схемам.
1.2.5. Информационные ресурсы
Информационные ресурсы представляют совокупность всех данных, имеющихся на предприятии. Информация является ключевой составляющей для управления бизнес-процессами. При описании процесса, определяется информация, используемая процессом и выдаваемая в качестве результата. Существует также справочная информация.
Информацию можно классифицировать по следующим признакам: место возникновения, стадия обработки, способ отображения, стабильность, функция управления . Различные классификации информации необходимы при анализе информационных потоков. Например, определение мест возникновения информации является основой организации безбумажного документооборота с вводом информации в местах ее возникновения. А для определения мест возникновения нужно разделить информацию на внешнюю и внутреннюю, чтобы учитывать поступление внешней информации и предусмотреть ее введение в систему.
В процессах используются обычно обозначения различных документов и файлов. При описании процессов для целей автоматизации необходимо учитывать носитель информации и детализировать документы до уровня полей. Поля используются в качестве места для ввода данных в программе, которые могут изменяться. Например, «Заказ» - это текстовый документ, содержащий поле «Наименование клиента» длиной до 128 символов.
При более укрупненном описании достаточно будет ограничиться документом «Заказ». В таком случае функция «Ввод заказа» будет выполняться без указания, какие именно данные вводятся в систему. При этом большинство средств описания бизнес-процессов позволяют в дальнейшем детализировать это описание при необходимости.
1.2.6. Продукты и услуги
Продукты и услуги являются результатом, создаваемым в ходе выполнения процесса и соответствующим требованиям клиентов процесса. Это не обязательно продукция компании. Для внутреннего процесса результатом может быть документ, предоставляемый начальству. Например, результатом процесса планирования продаж является «План продаж» компании в натуральном и денежном выражении. К этому плану руководство компании и служба производства, являющиеся клиентами процесса, предъявляют определенные требования в виде формата предоставления, сроков, и т.п.
1.2.7. Потоки
Представляя однородные элементы процесса в последовательности, получаем потоки.
• Функциональный поток - описывает последовательность выполняемых работ и может характеризоваться стоимостью и длительностью.
• Информационный поток - показывает перемещение таких объектов как бумажные документы, файлы, записи баз данных и т.д.
• Организационный поток - последовательность исполнителей процесса в порядке выполняемых работ.
• Поток ресурсов - раскрывает движение всех ресурсов в процессе. В литературе также встречается поток входов/выходов, показывающий ресурсы, используемые и потребляемые процессом, а также производимые продукты/услуги.
Потоки необходимы для анализа отдельных аспектов бизнес-процесса. Например, для анализа загрузки сотрудников лучше использовать организационный поток, чем процесс в целом.
1.2.8. Уровни описания процессов (декомпозиция)
Декомпозиция - прием, позволяющий представить сложную систему в виде нескольких более простых взаимосвязанных, вложенных систем. Такая форма представления позволяет анализировать процесс, не перегружая представление элементами, излишними для решения текущей задачи. Глубина декомпозиции определяется целями моделирования и, таким образом, задает степень детализации описания процесса. По аналогии с планированием можно проводить моделирование и описание бизнес- процессов «сверху-вниз» и «снизу - вверх».
В случае моделирования «сверх) - вниз» описываются все процессы системы начиная с верхнего уровня, т. е. сначала рассматривается все предприятие в виде комплекса взаимосвязанных функций, а затем раскрываются отдельные функции в виде взаимосвязанных бизнес-процессов.
При моделировании «снизу - вверх» выбирается один процесс (например, «Обработка заказа»), затем производится его описание и дальнейшая оптимизация под поставленные цели. Часто в этом случае описания системы предприятия в целом не происходит, а описывается только часть системы, взаимодействующая с описываемым процессом. В дальнейшем такая работа может быть продолжена путем включения других процессов в работу по бизнес-инжинирингу.
Каждая из методик моделирования имеет право на существование, а также свои достоинства и недостатки.
Описание системы бизнес-процессов предприятия «сверху - вниз» требует больших затрат ресурсов. При такой работе, как правило, ломаются устоявшиеся стереотипы, и часто результаты сложно внедрить без серьезного изменения существующей системы. Необходима детальная, предварительная проработка системы «миссии - стратегии - цели» компании.
При подходе «снизу- вверх» проще создать команду и добиться улучшений за небольшой срок, но эти улучшения будут носить локальный характер. Для такой работы достаточно проработки целей проекта по инжинирингу. Решения в пользу этого подхода принимаются с учетом более низких затрат и возможности испытать эффективность новой технологии без большого риска для компании в целом. В дальнейшем обученную команду сотрудников можно использовать для распространения опыта проекта на всю остальную компанию. Данная методика описывает именно такой подход к бизнес-инжинирингу.
Что же представляет собой многоуровневое моделирование бизнес-процессов? Функция (одно действие) процесса может представлять собой отдельный процесс и раскрываться уровнем ниже в виде отдельного процесса состоящего из нескольких операций .
Таким образом, повышая детализацию описания бизнес-процессов, можно сформировать структурную "вложенность" бизнес-процессов. Подобная структура является процессной моделью предприятия и должна содержать описание бизнес-процессов, определяя их взаимосвязи.
Уровень детализации описания отдельного бизнес-процесса диктуется необходимостью обеспечить качество понимания бизнес-процесса. Если какой-либо шаг процесса при данном уровне детализации остается непонятным, детализацию описания повышают. Если данного уровня детализации достаточно для однозначного понимания бизнес-процесса (определяющего удобство и эффективность работы с ним), то повышать детализацию не требуется (в целях экономии ресурсов).
Pasted from <http://www.regcons.ru/5-step-1-2.htm>
Форматы и средства описания бизнес-процесса
Все средства для описания бизнес-процессов можно разделить по формату представления на текстовые, табличные и графические. У каждого формата есть свои преимущества и недостатки
Текстовый формат описания в детальных пояснениях не нуждается. Это описание бизнес-процесса с использованием текста. Основное преимущество таких описаний - гибкость в выражении любых нюансов процесса средствами языка. Фактически для текстовых описаний бизнес-процессов не существует определенных стандартов, и предприятие может использовать любую удобную для него форму структурирования текстовой информации. Из этого следует и основной недостаток - слабая формализация описаний.
Для описания процесса в таблицах можно использовать следующий формат
Графа «№» - показывает порядковый номер функции. Для описания декомпозиции процесса можно использовать разряды номера функции. Например, у функции №7 есть три подфункции, их номера начинаются с номера декомпозируемой функции: 7.1; 7.2; 7.3.
Графа «Наименование функции» - включает название работы/ операции.
Графа «Исполнитель» обозначает сотрудника (должность) выполняющего соответствующую работу.
Графы «Ресурсы» включают всю совокупность используемых в процессе предметов и средств труда, а также документов.
Лучше всего использовать табличный формат для описания простых линейных процессов или для сбора информации для последующего графического описания
Графические описания бизнес-процессов в виде различных диаграмм пользуются сейчас наибольшей популярностью. Существует несколько широко распространенных нотаций или языков графического описания бизнес-процессов. В Методике приведены три наиболее популярные нотации описания бизнес-процессов.
IDEF (Integration Definition for Function Modeling - методология функционального моделирования) - семейство совместно используемых методов для процесса моделирования. Первоначально разработаны в военных ведомствах США. На сегодня эта техника описания бизнес-процессов получила наибольшее распространение в мире и принята как стандарт во многих странах. В России па момент написания Методики это зафиксировано в Р50.1.028-2001 "Информационные технологии поддержки жизненного цикла изделия. Методология функционального моделирования", а также в проекте стандарта: ГОСТ Р ИСО 10303-203 "Системы автоматизации производства и их интеграция. Представление данных об изделии и обмен данными. Протокол применения 203 - Проектирование изделия управляемой конфигурации". Концепция реализована во многих программных продуктах, наиболее популярным из которых на сегодняшний день является пакет BPW1N/HRWIN.
UML (Unified Modeling Language - унифицированный язык моделирования) -наиболее систематизированный подход к описанию любых систем, в т.ч. и бизнес-процессов. Позволяет перейти от описаний системы непосредственно к написанию компьютерных программ и - в значительной степени - сформировать основу будущего средства автоматизации. UML принят как стандарт для проектирования информационных систем более чем 60-ю ведущими разработчиками программного обеспечения, в т.ч. и Microsoft. Разработчик языка - некоммерческий консорциум Object Management Group (0MG). Наиболее популярным инструментом, поддерживающими язык UML, является Rational Rose.
ARIS (ARchitecture of Integrated Information Systems - проектирование интегрированных информационных систем) - германская технология описания предприятий. Разработана профессором Августом Вильгельмом Шеером (компания IDS Scheer AG). Используется как встроенное средство в одну из крупнейших на сегодняшний день систем автоматизации предприятий - SAP R/3. Пока имеет меньшее распространение, чем вышеперечисленные системы. При этом единственная методология, где фирма-разработчик является и производителем одноименного программного продукта, поддерживающего данную методологию. Этим обеспечивается практически единовременное совершенствование методологии и программной поддержки.
1.3.2. IDEF
Начнем рассмотрение с концепции IDEF как более простой и доступной в виде большого числа программных продуктов, поддерживающих эту концепцию (BPWIN, БИТ-Мастер, MS Visio и др.).
IDEF технология используется, начиная с конца 1980-х годов. Department of Defense USA (Министерство обороны США) является основным пользователем данной технологии. Ею пользуются также некоторые крупные корпорации в США.
Функции 1DEF могут детализироваться в отдельных схемах, это называется декомпозиция. На самом верхнем уровне это может быть все предприятие, отраженное как один блок, а далее - в отдельной схеме - будут раскрыты различные процессы.
1.3.3. UML как средство описания бизнес-процессов
UML - объектно-ориентированный язык моделирования для описания сложных систем. Также весьма распространен, существуют многочисленные инструменты для проектирования систем на данном языке, например: Rational Rose, Paradigm Plus, 4Keeps, MS Visio 2002 XP и др.
Данный язык описания содержит 8 различных типов диаграмм:
Диаграмма вариантов использования - показывает статический вид системы с точки зрения конечного пользователя.
Диаграмма классов - отражает статичные отношения между элементами модели.
Диаграмма состояний - показывает динамический вид системы, включающий состояния, переходы, события и виды действий.
Диаграмма деятельности - представляет собой поток управления между видами деятельности, отражает динамику системы.
Диаграмма последовательности - показывает временную упорядоченность сообщений. Диаграмма кооперации - показывает структурную организацию обменивающихся сообщениями объектов.
Диаграмма компонентов - статическое отображение организации совокупности компонентов и существующих между ними зависимостей.
Диаграмма развертывания - показывает организацию обрабатывающих узлов системы и размещение в них компонентов. Для описания бизнес-процессов применяются Диаграммы деятельности.
Диаграмма деятельности состоит из следующих элементов:
• Точка инициации - начало процесса.
• Точка завершения - окончание процесса. 29
• Действие - функция, работа или операция.
• Подпроцесс - обозначение блока, описанного детально в другой диаграмме.
• Исполнитель (роль, персона, должность, оргзвено).
• Решение - условие перехода при разветвлениях процесса.
• Объект - используемый в процессе ресурс.
• Ветвитель / синхронизатор - обозначение точек синхронизации исполнения параллельных задач или разветвление на несколько одновременно выполняемых операций.
1.3.4. еЕРС - событийно-функциональные диаграммы
Событийно-функциональные диаграммы (сокращенно еЕРС - extended event-process chain),
Диаграммы еЕРС описывают последовательность действий (работ, операций). Эти диаграммы позволяют отражать как последовательность действий, так и участников и используемые ресурсы (в т.ч. информационные).
&События показывают, что происходит в процессе, и отражают состояние. В отличие от функций, выполняемых в течение определенного срока, события отражают возникшее в результате выполнения функций состояние, т.е. констатируют факт и в этом смысле не имеют временной протяженности, как будто происходят мгновенно. Примеры функций:
• отправка заказа
• доставка товара
• разработка рекламного макета. Примеры событий:
• получена заявка от клиента
• товар доставлен
• проверка качества проведена
• рекламный стенд установлен. Для описания ветвлений процесса используются логические операторы.
• и--®
• или -®
• исключающее или - ®
Так как описание больших бизнес-процессов может стать неудобным из-за громоздкости, для лучшего структурирования описания существует возможность детализации каждой функции/операции процесса, называемая декомпозицией.
Pasted from <http://www.regcons.ru/5-step-1-3.htm>
1.4. Программная поддержка проектирования и автоматизации бизнес-процессов
1.4.1. Необходимость ведения электронной базы данных
Средства описания бизнес-процессов отличаются по функциональным возможностям, и выбрать нужное средство для поддержки проекта по оптимизации бизнес-процессов сложно. На сегодняшний день получили распространение следующие системы описания бизнес-процессов: Visio, BPWIN, ARIS-Toolset и Rational Rose
1.4.2.Сравнение инструментальных средств Visio, BPWIN, ARIS и Rational Rose
Visio - наиболее простое и доступное средство моделирования процессов. Этот продукт имеет стандартные, привычные всем панели управлении в стиле MS Office и легко интегрируется с любыми приложениями этого пакета, что упрощает работу с ним для неопытных пользователей. Однако для временного или стоимостного анализа требуется разработка отчетов, что значительно усложняет использование этого продукта. Типовые отчеты явно не достаточны для анализа бизнес-процессов. Несмотря на это, Visio является распространенным средством для описания бизнес-процессов как в России, так и за рубежом. Visio поддерживает IDEF и UML форматы для описания бизнес-процессов. Возможна также самостоятельная разработка форматов.
BPWIN - занимает промежуточное место, отличаясь достаточной простотой и большими возможностями анализа. Функциональность BPWIN заключается не только в рисовании диаграмм, но и в проверке целостности и согласованности модели. BPWIN обеспечивает логическую четкость в определении и описании элементов диаграмм, а также проверку целостности связей между диаграммами. Инструмент обеспечивает коррекцию наиболее часто встречающихся ошибок при моделировании. Кроме того, BPWIN поддерживает пользовательские свойства, которые применяются к элементам диаграммы для описания специфических свойств, присущих данному элементу. Основным ограничением этой системы является положенный в ее основу стандарт IDEF, в котором существуют жесткие ограничения при построении моделей. Это упрощает задачу при описании простых процедур, но усложняет описание больших процессов. Схемы 1DEF при описании сложных процессов начинают представлять бесчисленное множество взаимосвязанных схем, внешне очень похожих, что затрудняет понимание процесса в целом. Часто не удается представить нужную степень точности описания на 1 схеме.
ARIS - рассматривает предприятие как совокупность четырех взглядов (views):
• взгляд на организационную структуру;
• взгляд на структуру функций;
• взгляд на структуру данных;
• взгляд на структуру процессов.
ARIS позволяет составлять диаграмму целей, связывая процессы через цели с миссией компании. В результате после построения бизнес-модели получается комплексное видение компании: Цели - Процессы - Оргструктура - Данные -Продукты/услуги в виде отдельных, но связанных через объекты диаграмм. Это означает, что при изменении названия должности на одной диаграмме сразу корректируются названия во всех процессах, где она присутствует, и в оргструктуре
При этом каждый из данных взглядов разделяется еще на три подуровня: • описание требований; • описание спецификации; • описание внедрения.
Итак, ARIS предлагает рассматривать организацию с позиции 4-х аспектов, отображающих разные взгляды на предприятие, а также разную глубину этих взглядов. Для описания бизнес-среды предлагается использовать 85 типов моделей (обычно в практической деятельности применяется не более 6-7 типов моделей), каждая из которых принадлежит тому или иному аспекту. ARIS Toolset является, с одной стороны, достаточно сложной для освоения системой. С другой стороны, диаграммы бизнес-процессов в готовом виде понятны даже неподготовленным сотрудникам, это позволяет эффективно организовывать работу команд, не прибегая к тотальному обучению всех работающих над проектом сотрудников.
Rational Rose - CASE-средство фирмы Rational Software Corporation (США), предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанный ими универсальный язык для моделирования объектов (UML - Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder. Ada, SQLWindows и ObjectPro). Основной вариант - Rational Rose/C++ -позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на C++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.
Pasted from <http://www.regcons.ru/5-step-1-4.htm>
1.5. Методы анализа и оптимизации процессов
Основные предложения но оптимизации появляются из простого логического анализа описания процесса. Становятся очевидными такие факторы как: дублирование операций, неэффективное распределение должностных обязанностей и частая передача результатов из отдела в отдел. При проведении общего анализа логики процесса важно привлекать специалистов по информационным технологиям и других, не задействованных в процессе участников. Многие предложения можно сделать только на основе знания новых технологий, имея при этом независимый "взгляд со стороны" на процесс.
1.5.1.Устранение неэффективных процедур
Например, в следующем процессе происходит несколько последовательных согласований договора. При этом, возможно, некоторые из них - сложившаяся формальность. Такие функции должны исчезнуть из процесса «как надо». В данном процессе «лишним» оказалось согласование договора с Гл. инженером. В результате процесс сократился до 6 функций.
Процесс согласования/утверждения договора «как есть»
Выполняя такой анализ, надо задавать вопрос для каждой функции: а возможно выполнение процесса без этой операции?
В примере
согласования договора Юристом, можно избежать, например, составлением типовых договоров. А договоры на закупку канцелярии не обязательно согласовывать с Главным инженером и Коммерческим директором.
1.5.2. Распределение ответственности за выполнение бизнес-процесса и делегирование полномочий по принятию решений.
Наиболее часто встречающимся примером расширения ответственности является делегирование полномочий по принятию решений по расстановке лимитов, к рамках которых работает определенное должностное лицо. Например, в том же процессе «Согласование договора» может быть установлено следующее:
1. При сумме договора менее 5000 руб. решения принимаются Менеджером по закупкам.
2. При сумме договора до 50000 руб. решения принимаются Начальником отдела закупок.
3. При сумме договора до 200000 руб. решения принимаются Коммерческим директором.
4. При суммах договоров свыше 200000 руб. решения принимаются Генеральным директором.
В итоге снимается нагрузка с менеджеров высшего звена и ускоряется согласование договоров на небольшие суммы. При этом может применяться система выборочного контроля за принятием решений подчиненными.
1.5.3. Связывание параллельных работ.
При создании сложных продуктов (как информации, так и материальных ресурсов) возникают ситуации, когда несколько подразделений выполняют параллельные работы, затем пытаются согласовывать полученный результат. Примером бизнес-процесса такого рода является процесс формирования финансового плана предприятия.
В начале процесса параллельно во времени выполняется планирование продаж и производства, при этом Служба производства пользуется 48 фактической информацией по объему производства предыдущего периода и оптимизирует загрузку производства на плановый период с учетом производственных возможностей, а отдел сбыта ориентируется на потребности рынка. После получения предварительных вариантов планов проводится их согласование в ПЭО. Результатом этого согласования может быть как изменение плана продаж, так и изменение плана производства. Чаще всего такого рода процессы организованы неэффективно и приводят к дублированию функций в подразделениях и увеличению сроков формирования финансового плана.
1.5.4.Фиксирование информации у источника и включение обработки информации в реальную работу
Использование данного принципа подразумевает занесение информации в единую учетную систему один раз, на месте ее возникновения. Следствием применения принципа является сокращение документооборота между подразделениями, снижение количества ошибок при передаче информации, сокращение времени выполнения процесса и т.д.<
1.5.5. Стоимостной анализ
1.5.5.1. Понятие функционально-стоимостного анализа
Функционально-стоимостной анализ (ФСА) или его зарубежное название Activity-Based Costing (ABC). Метод был разработай для ведения более точного учета затрат на основе дополнительных данных, получаемых на основе анализа бизнес-процессов
Основное отличие его от других методов учета заключается в использовании операций как объекта учета затрат. В классических методиках учета стоимость ресурсов, используемых при производстве и продаже, списывается на продукцию прямо (direct costing) или распределяется по рассчитываемым базам (standard costing). Метод ABC 51 предполагает расчет стоимости операции, выполняющихся при производстве продукции, а затем калькуляцию себестоимости на основе данных о затратах на операции.
Основной плюс такого учета - возможность анализа бизнес-процесса в затратах по операциям. Это позволяет рассчитывать эффективность принимаемых решений по оптимизации бизнес-процесса
Отрицательной стороной такого вида учета является его сложность и, следовательно, высокие издержки.
Здесь необходимо найти оптимальное соотношение между эффектом от повышения точности учета, возможности эффективного анализа, принятия решений и повышающимися затратами на учет
1.5.5.2. Сущность метода. Ресурсные и Операционные драйверы
Появление новых объектов учета - операций - приводит к необходимости установления соотношений между ресурсами и операциями, а также операциями и продуктами.
Например, за последний месяц в компании продано 1000 тт. изделий «А» и 15000 изделий «Б». Как распределить стоимость операции «Обработка заказа» на изделия? Для этого нам необходимо узнать, сколько было принято заказов на изделия «А» и «Б». Собрав статистические данные за месяц, определили, что на изделие «А» поступило 100 заказов, а на изделии «Б» только 50. Соответственно для распределения затрат рассчитываем простую пропорцию:
всего заказов за период было: 50+100=150 Из них на продукт
«А» приходится: 100/150-66% и на продукт
«Б»: 50/150 = 33%
Это и будут драйверы операции «Обработка заказа».
Одной из самых сложных проблем ABC является точный расчет драйверов ресурсов и операций. Здесь возможны различные варианты: от непосредственного измерения до усредненных оценок за период деятельности. Непосредственный учет может быть организован на автоматизированном производстве. В обычных условиях этот вид учета требует значительных затрат. Ниже приведен пример оценки потребления ресурсов операциями по двум способам:
За месяц в фирму поступило 100 заказов. Приемкой заказов занимается Менеджер по продажам с окладом в 5000 руб.
1. Усредненная оценка. Для расчета потребления трудового ресурса операцией можно разделить заработную плату Менеджера по продажам на количество заказов. Стоимость трудозатрат обработки одного заказа составит: 5000/100 = 50 руб.
2. Прямое измерение.
В случае использования автоматизированной системы, которая фиксирует начало заполнения заказа (внесения информации о клиенте) и окончание работы над заказом Менеджера по продажам, можно получить отчет по затратам рабочего времени на обработку каждого заказа и провести анализ: какие заказы требуют большего времени и, следовательно, требуют больших трудозатрат. Отчет может быть сгруппирован по видам продукции:
Продукция Среднее время обработки заказа
Холодильники 15 мин.
Телевизоры 25 мин.
Видеомагнитофоны 30 мин.
В данной таблице приведен отчет о времени обработки заказов на разные виды продукции.
1.5.5.3. Качественные показатели процесса и драйверы издержек
Рассмотренные в предыдущем разделе драйверы - это еще не все составляющие ABC подхода. Кроме потребления ресурсов операциями и внесения вклада операции в объект стоимости, существует еще процесс, выполняющийся определенным образом. Для измерения качества выполняющегося процесса существует отдельный показатель - это драйвер издержек «cost driver». Драйвер издержек непосредственно не связан с распределением затрат на объекты стоимости, он показывает эффективность выполнения процесса. В зависимости от процесса, выбранного для анализа, методы расчета драйвера будут различны. Приведем несколько примеров.
Пример 1. Процесс обработки заказов. Процесс состоит из 4х функций:
1. Развитие контакта с клиентом - прием звонков и выяснение потребностей клиента.
2. Обработка запроса клиента - рассмотрение возможностей предложить комплекс продуктов/услуг, удовлетворяющих потребности клиента.
3. Формирование предложения клиенту.
4. Формирование заказа - формирование заказа на производство на основе принятого клиентом предложения.
Для этого процесса можно использовать драйвер издержек - количество обращений клиентов и соотношение между количеством обращений и количеством запросов/предложений и заказов
На основе анализа статистических данных была получена следующая информация (за месяц): 54
• Развитие контакта с клиентом 100 обращений.
• Обработка запроса клиента - 90 запросов.
• Формирование предложения клиенту-67 предложений.
• Формирование заказа- 16 заказов.
Фактически количество обращений, запросов, предложений и заказов равно количеству выполненных соответствующих функций. Например, количество контактов с клиентами равно количеству выполненных функций «Развитие контакта с клиентом». Естественно, при этом учитываются и те функции, когда этот контакт не приводит к дальнейшему продолжению процесса, т.е. когда клиент уже на этапе первичного контакта по каким-то причинам прекращает с нами сотрудничество. В результате соотношение между этими показателями определяет, насколько эффективен процесс или какова доля заказов в первичных контактах с клиентами. В данном примере на 100 обращений приходится 16 заказов.
Все драйверы могут функционировать, как минимум, на четырех уровнях:
1. Изделия (Unit) - драйверы, установленные для каждого изделия. Например, время шитья чехла для матраса.
2 Партии (Batch) - драйверы, установленные для каждой партии. Например, настройка станка.
3. Продуктовой линии (Product) - драйверы, установленные для всех изделий. Это типично для операций разработки изделий.
4. Предприятия (Facility) -драйверы, не связанные с продукцией.
ABC - это не панацея от всех бед. Использование ABC-метода для учета стоимости объектов издержек, например, продукции, имеет недостатки. ABC дает отчет по всем издержкам за определенный период, но не рассматривает списание расходов с большим сроком окупаемости, за исключением тех, по которым существует специальная отчетность (амортизация и т. д.). Например, если большое количество расходов для отдела НИОКР за ограниченный промежуток времени будет отнесено на продукцию, то это чрезмерно увеличит ее себестоимость. Подобные искажения могут возникать и в случае с сезонной продукцией. В жизненном цикле любой продукции имеется период начальных вложений, связанный с созданием прототипов и тестированием. В общем итоге им уделяется меньшее внимание, и стоимость стабилизируется. ABC измеряет расходы в течение определенного периода. Благодаря представлениям, полученным с помощью ABC, не популярный на сегодня учет издержек жизненного цикла продукта, вероятнее всего, начнут признавать.
1.5.6. Временной анализ
Для выполнения временного анализа можно воспользоваться следующей последовательностью:
1. Определение частоты выполнения функций
Здесь необходимо собрать статистику за некоторый период - как часто выполняются те или иные функции в процессе. Даже в простых процессах не всегда функции выполняются одинаковое количество раз. Например
В процессе "Продажи автомобилей" есть 4 функции:
1. Развитие контакта с клиентом
2. Обработка запроса клиента
3. Формирование предложения клиенту
4. Формирование заказа
«Развитие контакта с клиентом» происходит в 100% случаев, так как это стадия включает первичный контакт. «Обработка запроса клиента» осуществляется лишь в 90% случаев - остальные клиенты не делают запроса. 67% процессов содержит функцию «Формирование предложения клиенту» — остальные компания просто не в состоянии удовлетворить, исходя из ассортимента и возможностей поставки. Процесс «Продажи автомобилей» только в 16% случаев содержит функцию «Формирование заказа», так как на остальные запросы клиенты просто не отвечают. Соответственно, для анализа времени выполнения процесса нужно учитывать, что не каждый процесс закончится «Формированием заказа» и, соответственно, длительность этих процессов будет различна.
2. Определение длительности выполнения операций.
Для использования временного анализа процесса необходимо определить длительность выполнения операций. Измерение длительности выполнения операций можно либо проводить непосредственно, либо экспертно определять приблизительное время выполнения операций. Можно также рассчитать среднее время выполнения операции, определив количество операций за некоторый период, например:
Менеджер по работе с клиентами занимается приемкой заказов клиентов.
• Количество принимаемых за месяц заказов (п) = 100.
• Количество рабочих дней в месяце (D) = 20.
• Время работы (t) = 8 час. • Среднее время обработки заказа = D*t/n = 20 * 8/100 = 1.6 часа.
При подобных расчетах нужно учитывать, что это не только длительность выполнения самой операции, но и время простоев (ожидания) и т.п.
Для непосредственных измерений нужна система учета рабочего времени. Например, для того же Менеджера можно точно определить время обработки одного заказа, если он будет - после приема каждого заказа - заносить потраченное время в отчетную форму или программу учета рабочего времени. Это может быть введено только на месяц (для анализа полученной статистики) или использоваться постоянно (возможно, даже в системе мотивации). При использовании ARIS Toolset возможно назначение минимального среднего и максимального времени выполнения каждой операции. Кроме времени выполнения операций, может использоваться также время ожидания и время координации.
Pasted from <http://www.regcons.ru/5-step-1-5.htm>
1.6. Автоматизация процесса - Workflow
1.6.1. Понятие Workflow
После проведения оптимизации бизнес-процессов возникает необходимость применения современных технологий для выполнения процесса с наибольшей скоростью, наименьшими затратами и максимальной эффективностью. Для этого применяются средства автоматизации. Системы автоматизации бизнес-процессов имеет смысл внедрять только после предварительной оптимизации, чтобы избежать затрат на автоматизацию неэффективных процессов. Поэтому мы сначала рассмотрели все методы работы с процессами и только теперь переходим к автоматизации. Что же такое автоматизация бизнес-процессов или Workflow?
При раскрытии основных определений лучше всего обращаться к первоисточникам. На сегодняшний день стандартизацией в области Workflow занимается Workflow Management Coalition. В официальном документе по терминологии дано следующее определение
Workflow - это полная или частичная автоматизация бизнес-процесса, при которой документы, информация или задания передаются от одного участника (бизнес-процесса) к другому для выполнения действий согласно набору руководящих правил.
Workflow - в дословном переводе с английского означает поток работ /операций.
Вот еще одно определение, наилучшим образом отражающее процессную сущность Workflow
Workflow - это процесс, произвольное задание, выполняемое последовательно или параллельно двумя или более участниками рабочей группы с целью достижения общей цели.
Фактически, Workflow является синонимом термина «бизнес-процесс», только применяется чаще в отношении систем автоматизации бизнес-процессов. После проведения описания и оптимизации бизнес-процессов следующим шагом будет процессная автоматизация. Для того, чтобы выстроенные процессы стали работать, необходимо средство для автоматической координации деятельности исполнителей - это и есть системы Workflow. В отличие от рассматривавшихся ранее систем проектирования и оптимизации бизнес-процессов (бизнес-моделирования), системы Workflow используются для автоматизации текущей деятельности. То есть, позволяют документам автоматически проходить заданные маршруты и получать отчеты, как по содержанию документов, так и по процессу
Кроме Workflow, существуют еще технологии Groupware и системы управления документами (СУД). Необходимо понимать, что это не одно и то же.
СУД - это самое узкое из приведенных понятий, которое подразумевает управление только документами, а это еще не все процессы компании. Основное отличие СУД от Workflow - в большей ориентированности на документ. Практически все СУД содержат большое количество функций для работы с документами, которые есть далеко не во всех системах Workflow. Например, поиск документа по ключевым словам. В системах Workflow документ является лишь одним из объектов в процессе. Существуют системы Workflow, обладающие полным функционалом систем управления документооборотом. Одной из характерных черт систем автоматизации Workflow является графический построитель процессов.
Под Groupware понимают системы организации групповой работы. Это более широкое понятие, чем Workflow. Системы Groupware могут включать в себя Workflow как составную часть. При этом термин Groupware - наименее определенная категория, и такие системы могут включать различный функционал, в общем отражающий организацию групповую работы.
Workflow, ориентированная на информацию и автоматизацию, имеет свою специфическую терминологию. Одним из понятий является объект это информационный, материальный или финансовый объект, используемый в бизнес-процессе (например: письмо, оборудование, счет). Объектом может быть любой ресурс, используемый в процессе.
1.6.2. Представление бизнес-процесса как Workflow
Все ли бизнес-процессы могут быть описаны, как процессы Workflow? Какие бизнес-процессы целесообразно представлять в виде процессов Workflow?
Важнейшей особенностью технологии Workflow является поддержка управления процессами, содержащими как автоматизированные - выполняемые средствами информационных систем, так и неавтоматизированные - выполняемые вручную -операции. Благодаря этой особенности, любой бизнес-процесс предприятия может быть представлен в виде процесса Workflow, если, конечно, этот процесс:
• выделен;
• структурирован;
• выполняется по правилам, которые можно сформулировать;
• периодически повторяется
Первые три ограничения являются ответом на вопрос «какие процессы можно описать», а последнее - «какие целесообразно».
Хотелось бы обратить внимание на следующие немаловажные обстоятельства
Внедрение системы класса Workflow базируется не на маршрутизации прохождения документов и не на автоматизации группы операций или вида действий, а на описании бизнес-процесса, ради эффективного выполнения которого, собственно, и осуществляется маршрутизация документов и/или автоматизация операций.
Технология Workflow не накладывает каких-либо специальных ограничений на уровень детализации бизнес-процесса и/или степень автоматизации выполняемых операций.
При всей важности функционального моделирования, тем не менее, представленных в функциональной модели данных еще недостаточно для полного определения процесса. Третьим требованием представления бизнес-процесса в виде процесса Workflow является наличие правил выполнения процесса, которые можно сформулировать и формально описать. В первую очередь, соответствующие правила касаются последовательности выполнения операций, условий и предусмотренной реакции на внешние события
Будем рассматривать операции, выполняемые группой исполнителей. В качестве направлений систематизации выберем согласованность времени выполнения (синхронно, асинхронно) и области действия (локальная или распределенная). Для выполнения синхронных, локальных операций требуется наличие всех исполнителей в одно время и в одном месте. Синхронные распределенные операции выполняются в одно и то же время исполнителями, которые могут находиться в разных местах. Асинхронные, локальные операции выполняются членами группы в одном, определенном месте, но в различное время. И, наконец, асинхронные распределенные операции выполняются членами группы исполнителей в различных местах и в различное время.
В рамках технологии Workflow рассматриваются операции, относящиеся к последней категории, - распределенные и асинхронные, Причем эти операции могут выполняться последовательно или параллельно, иметь сколь угодно сложную логику, согласовываться по времени, данным и исполнителям. Четвертым и последним требованием представления бизнес-процесса в виде процесса класса Workflow является периодичность выполнения. В отличие от предыдущих требований, это требование носит экономический характер.
1.6.3. Инструментальные средства описания процесса
С точки зрения системы, каждая операция, входящая в состав процесса, содержит задание, выполнение которого предполагает ввод и/или обработку информации. Типовыми параметрами описания операции являются следующие:
• адресат - пользователь или группа пользователей, получающих задание, при этом указываются права на пересылку задания другому пользователю и права на копирование данных, относящихся к заданию;
• экранная форма - это документ, содержащий предназначенные для заполнения пустые места, в которые вводятся данные;
• предельный срок выполнения задания, определяющий, до какого времени соответствующая операция должна быть выполнена;
• действия системы при инициализации и завершении операции.
Последовательность выполнения операций и условия их перехода от одной к другой составляют алгоритм выполнения процесса. Помимо уже рассмотренных операций, в описании алгоритма, как правило, используются:
• логические условия;
• внешние по отношению к процессу события;
• средства создания параллельных ветвей;
• точки встречи, позволяющие согласовать результаты параллельно выполняемых операций;
• автоматические операции - операции, выполняющиеся без участия пользователя:
• сценарии - экранные формы, содержащие вызов функций, операторов системы и внешних программ, используемых пользователем при выполнении различных операций.
Использование инструментальных средств описания процессов в большинстве современных систем класса Workflow не требует от разработчика каких-либо знаний в области программирования или систем управления базами данных.
При выполнении процесса Workflow информация передается от пользователя к пользователю в виде некоторого упорядоченного множества данных. Каждая операция использует подмножество этих данных, состав которого, а также способ представления данных задаются соответствующей экранной формой. Создание форм является прерогативой разработчика процессов, а инструментальные средства для разработки форм являются важным компонентом системы Workflow. Главным требованием к экранным формам, циркулирующим в системе, является их «интеллектуальность» - возможность динамически изменять состав, содержание и формат представления данных.
Большинство систем поддерживают самые разнообразные типы данных. Очень важными являются данные типа «файл», благодаря которым обеспечивается возможность ассоциировать с формой файлы, находящиеся вне системы. Разработчик указывает операции, на которых эти файлы должны порождаться, и регламентирует возможность внесения в них изменений.
Значения данных представляются в экранной форме в виде полей. При этом различаются:
• демонстрационные поля - поля, содержащие значения, для которых не допускается редактирование;
• обязательные поля - поля, которые необходимо заполнить в процессе выполнения задания;
• необязательные поля - поля, значения которых могут быть введены пользователем, однако это не является необходимым условием выполнения задания;
• вычисляемые поля - поля, значения которых вычисляются в соответствии с заданными правилами;
• невидимые поля - вычисляемые, но не отображаемые на экране.
Построение форм представления данных является составной частью описания операций, составляющих процесс Workflow, и включает:
1. задание и форматирование текста, образующего форму;
2. определение требуемого подмножества данных;
3. указание способа их представления в форме;
4. описание условий и обстоятельств, определяющих содержание формы. Кроме того, для каждого поля могут быть заданы:
5. справка-пояснение того, как это поле заполнить; справочная информация будет выдаваться на экран по требованию пользователя;
6. диапазон или список допустимых значений:
7. одна или несколько таблиц, определяющих взаимосвязи между значениями полей формы.
Использование таблиц позволяет организовать согласованную работу с логически связанными полями данных, например, такими, как название компании и ее почтовый адрес.
В большинстве современных систем класса Workflow присутствуют высокоуровневые инструментальные средства создания и редактирования экранных форм.
1.6.4.Управление выполнением процесса
Любой конкретный случай выполнения процесса называется экземпляром (вариантом, сессией). Например, процесс «Обработка заказа клиента». Экземпляром процесса будет обработка заказа № 125 от компании «Стройтрест». Выполнение любого экземпляра состоит в рассылке пользователям заданий в виде экранных форм и управлении процессом их заполнения в соответствии с предусмотренным алгоритмом. При этом система класса Workflow обеспечивает;
• одновременное выполнение множества экземпляров каждого процесса;
• передачу заданий между операциями процесса посредством системы электронной почты;
• обмен произвольными сообщениями между пользователями;
• доступ к функциям системы и внешним программам, предусмотренным для пользователя разработчиком процесса;
• взаимодействие путем обмена данными с другими программами. Работа пользователя с любой формой состоит из следующих действий:
• просмотр содержимого;
• заполнение и/или редактирование полей;
• печать формы;
• выпуск формы для последующей обработки.
Часто при заполнении экранных форм поддерживается технология электронной подписи.
В процессе эксплуатации система Workflow накапливает задания, ожидающие обработки, и формирует очереди заданий различных типов как для каждого пользователя, так и для группы. Автоматически производится периодическое обновление очередей и уведомление пользователя о наличии в очереди новых, еще не просмотренных заданий, заданий с высоким приоритетом или заданий с установленным предельным сроком выполнения.
Набор операций для работы с очередью заданий содержит следующие операции:
• выбор задания;
• переход к заполнению экранной формы выбранного задания;
• выпуск выбранного задания - информирование системы о его выполнении;
• пересылка выбранного задания другому пользователю в случае невозможности его выполнения;
• установка критериев сортировки заданий в очереди;
• ограничение списка отображаемых заданий посредством критерия-фильтра;
• управление периодом обновления очереди.
После выпуска или пересылки задания оно автоматически удаляется из очереди. В управлении и выполнении процесса Workflow участвуют следующие классы пользователей;
• администратор системы - поддержка и сохранение целостности всех данных, не относящихся к процессам, например, данных о пользователях;
• разработчик процесса - разработка, тестирование и поддержка конкретного процесса;
• владелец процесса - редактирование конкретного процесса;
• менеджер - контроль исполнения экземпляров процесса посредством регистрационных отчетов и сервисных программ;
• пользователь - доступ к системе через очередь заданий, функция запуска экземпляра конкретного процесса и справочная подсистема.
Каждый пользователь имеет уникальный код, пароль и относится к некоторой группе пользователей. Средства управления доступом системы Workflow ограничивают доступ к операциям, к функции запуска экземпляров процесса и к возможностям администрирования для определенных пользователей или групп пользователей. Кроме того, большинство систем предоставляют возможность управления доступом на уровне ролей, в соответствии с которой права доступа могут назначаться не физическим лицам или подразделениям, а должностям (ролям).
Для контроля и управления текущим состоянием выполнения экземпляров процесса в системах Workflow предусмотрены следующие функции:
• регистрационные журналы;
• отчеты о состоянии;
• пересмотр данных;
• административные отчеты.
Регистрационный журнал представляет собой внутренний отчет системы, в котором для каждого экземпляра процесса фиксируются дата и время каждой транзакции, выполненное действие и исполнитель. С помощью регистрационного журнала в любой момент времени можно получить информацию о том, что происходило и происходит при выполнении конкретного экземпляра процесса.
Отчет о состоянии - это внутренний отчет системы, в котором отражается текущее состояние каждой операции каждого процесса. Различается четыре типа состояний: выпущена, не выпущена, отозвана, не отправлена. Кроме того, для любой операции можно получить данные о текущих значениях полей. Функция пересмотра данных отличается от отчета о состоянии лишь тем, что позволяет модифицировать значения полей и, таким образом, управлять выполнением экземпляра процесса.
Административные отчеты используются для сбора и обобщения информации, относящейся к нескольким (всем, текущим или завершенным) экземплярам данного процесса. Типичными примерами административных отчетов являются отчеты об объеме продаж в регионе, о суммарном объеме всех принятых заказов или о количестве просроченных договоров. Структура и алгоритм административных отчетов определяются разработчиком процесса.
1.6.5.Стратегия внедрения и использования
Какова иерархия целей такого проекта? Как эффективно организовать работы по сопровождению и развитию системы?
Цели внедрения систем Workflow:
1. управление выполнением бизнес-процессов. Внедрение технологии Workflow позволяет организовать конвейер обработки информационных, финансовых и материальных потоков на основе согласованного выполнения операций, работ и заданий, не ограничивая при этом творческую и деловую активность исполнителей, ответственных за конкретный участок работ;
2. сбор, организация хранения и доступа к документам и данным, используемым при выполнении бизнес-процессов. При этом, если системы типа «электронный архив» уделяют основное внимание вопросам регистрации, учета, индексации, хранения и поиска документов, то системы класса Workflow устанавливают связь между документами и операциями бизнес-процесса, управляют правилами прохождения документов, доставкой «тому, кому нужно, и тогда, когда нужно»;
3. получение достоверной информации о деятельности компании, анализ которой служит основанием для принятия управленческих решений и своевременной корректировки стратегии развития;
4. интеграция отдельных «островков автоматизации», существующих в различных подразделениях предприятия, в единую информационную систему поддержки выполнения бизнес-процессов. Такая интеграция позволяет избежать дублирования и несогласованности данных, используемых в различных подразделениях.
5. Необходимо отметить, что проект анализа деятельности и реорганизации бизнес- процессов предприятия и проект внедрения системы класса Workflow представляют собой далеко не одно и то же. Это последовательные шаги, необходимые для внедрения комплексной системы управления. Внедрение Workflow без предварительного описания и оптимизации бизнес-процессов приведет к автоматизации непонятно по каким принципам созданной системы - т.е., некоего неоптимального состояния.
6. Предположим, однако, что соответствующие работы выполнены, система инсталлирована, бизнес-процессы описаны, организационные вопросы решены, проведено тестирование и осуществлен переход к промышленной эксплуатации системы. Начиная с этого момента, главной задачей является поддержание системы в актуальном состоянии, отражающем особенности текущего состояния рынка, стратегию и тактику деятельности предприятия.
7. Технология выполнения соответствующих работ разработана весьма подробно. Ее квинтэссенцией является цикл управления эксплуатацией и развитием системы класса Workflow
Выполнение множества процессов Workflow (блок "Выполнение") сопровождается сбором статистики, представленной в отчетах различных типов. Эти отчеты служат основой для выявления типовых маршрутов выполнения процессов, распределения затрат, причин нарушения сроков выполнения отдельных операций (блок "Разбор"). Полученные данные сравниваются с требованиями, предъявляемыми к системе, проводится оценка эффективности эксплуатации (блоки "Сравнение" и "Требования"). На основании результатов сравнения проводится перенастройка описанных процессов, уточнение интерфейсов с прикладными программами и базами данных, уточнение состава отчетов (блок "Настройка"). Отредактированные версии процессов поступают в блок "Выполнение", а соответствующие им изменения в правилах организации бизнеса (блок "Изменения") влияют на требования, предъявляемые к системе (блок "Требования").
1.6.6. Сравнение систем управления Workflow
В заключение раздела автоматизации бизнес-процессов рассмотрим несколько систем Workflow, представленных на российском рынке
Сравнение систем управления потоками работ Workflow
Pasted from <http://www.regcons.ru/5-step-1-6.htm>
1.6. Автоматизация процесса - Workflow
2.1. Выбор процесса для оптимизации
Первый шаг - выбор процесса, над которым будет вестись работа по оптимизации. Выбор может осуществляться следующими методами:
• Функционально-стоимостным анализом (ФСЛ) деятельности компании.
• Экспертно.
• Комплексным подходом.
Применение метода ФСА предполагает определение стоимости основных выполняемых в компании функций и выбор процесса с наибольшей стоимостью, так как в результате его оптимизации будет получен максимальный эффект. Оптимизация процесса, который составляет 0.5-1% от общих затрат компании, не может дать значительного эффекта. Даже если удастся сократить затраты процесса на 50%, то в масштабах компании это будет только 0,25 - 0,5% от общих затрат, т.е., затраты на оптимизацию могут не окупиться.
Проведение проекта по оптимизации бизнес-процесса включает следующие затраты;
Обязательные затраты:
1. обучение персонала;
2. отвлечение персонала от основной работы (как на обучение, так и на проведение самого проекта).
Не обязательные, но желательные затраты:
3. покупка программного обеспечения:
4. привлечение консультантов.
Все эти затраты должны окупаться мероприятиями, проводимыми по оптимизации бизнес-процессов.
Основное преимущество ФСА - беспристрастность и сравнимость различных процессов по единому критерию затратности.
Недостаток - значимость процесса зачастую определяется не только его стоимостью, а это уже не учитывает метод ФСА.
Экспертный подход предполагает опенку значимости процессов компании специалистами. Причем, специалисты могут быть как сотрудниками компании, так и привлеченными консультантами.
Примером процесса в целом малозатратного, но вызывающего задержки в обслуживании клиентов, может стать процесс обслуживания клиентов в банке. С одной стороны, постоянное наличие запаса бумаги у операциониста и организация пополнения этого запаса не создают значительных затрат, но отсутствие бумаги может привести к задержке в обслуживании и к потере клиентов. Такие затраты сложно оценить потому, что информация о них не содержится в отчетах. Эти затраты называются издержками упущенных возможностей, и именно их стоит искать при использовании экспертного подхода.
Преимущество экспертного подхода - учет максимально возможного количества факторов. Недостаток - возможная пристрастность участников. Сложно сравнивать различные процессы без единого критерия оценки. Комплексный подход включает в себя экспертную оценку с учетом предварительно проведенного ФСА.
Многие руководители считают, что точно представляют, в чем заключаются проблемы организации, но когда «проблемные» процессы выбирались для оптимизации, оказывалось, что проблема находилась в смежных областях. Например, приглашались консультанты для решения проблем в управлении финансами. В результате выполнения проекта оказывалось, что улучшение контроля и управляемости финансов не решает проблемы организации, так как свое начало проблемы берут в снабжении и производстве, а финансы лишь отражают последствия.
2.1.1.Пример «Сертификация». Описание ситуации
Организация сферы оптовой торговли работает с фармацевтическими товарами. Согласно существующему законодательству, продукция подвергается обязательной сертификации.
Проблема. При проведении анализа товаров на складе было выявлено, что сроки хранения по разным партиям поставки сильно различаются. Это было вызвано различным временем сертификации товаров, в ходе которой продукция залеживалась на складе и не могла быть открыта в продажу без сертификата. Отсюда - замораживание оборотных средств компании и запаздывание выпуска товаров в продажу. Кроме того, бывали случаи несоответствия продукции требованиям стандартов, продукция возвращалась поставщику или уничтожалась, что также связано со значительным отвлечением средств из оборота и взысканием с поставщика убытков.
2.1.2. Пример «Сертификация». Выбор процесса
Процесс сертификации был выбран для описания и оптимизации, исходя из необходимости сокращения цикла товарооборота и уменьшения величины оборотного капитала замороженного в виде складских остатков. Сертификация - один из наиболее продолжительных процессов в организации.
Описание процесса.
Документы для сертификации приходят вместе с партией товара. Приемка товара осуществляется Кладовщиком совместно с Товароведом. Документы, необходимые для сертификации, передаются Кладовщиком Специалисту по сертификации. Для сертификации также используются образцы товара, они отбираются при приемке Кладовщиком и передаются Специалисту по сертификации. При некомплектности сопроводительной документации недостающие документы запрашиваются у поставщика. Доставка образцов товара и документации в сертификационный центр осуществляется курьером с автомобилем.
Сертификационный центр проводит Сертификацию продукции, результатом которой может быть либо выдача Сертификата, либо мотивированный отказ.
Среди причин отказа могут быть;
1. несоответствие сопроводительной документации товару;
2.несоответствие документации на новый товар устаревшим актам, используемым Сертификационным центром; несоответствие образца требованиям стандартов.
Курьер забирает результаты сертификации (сертификат, мотивированный отказ, сопроводительную документацию, оставшиеся после испытаний образцы и счета за сертификацию), и после доставки в организацию они передаются Специалисту по сертификации. В случае успешного завершения сертификации (получении Сертификата), товар открывается в продажу. Специалист по сертификации передает Сертификат в Отдел продаж Менеджеру по продажам, и товар запускается в продажу.
В случае получения мотивированного отказа, Специалист по сертификации анализирует причины отказа и принимает решение либо о получении дополнительной документации и повторной сертификации, либо о выставлении претензии поставщику, за которым следует возврат или уничтожение товара. Возвратом и уничтожением товара занимаются Менеджеры по закупкам, которые также ведут работу с поставщиками по получению недостающих документов.
Pasted from <http://www.regcons.ru/5-step%202-1.htm>
2.2. Формирование рабочей команды
Команда должна состоять как из участников процесса, так и из не задействованных в процессе сотрудников. Это необходимо для непредвзятого взгляда со стороны на установившиеся традиции при выполнении процесса, когда только не задействованный в процессе сотрудник может поставить под сомнение кажущиеся неоспоримыми правила. Наиболее подходящими кандидатами из не участников процесса будут специалист по ИТ, специалист отдела развития. Мог\т быть и специалисты других направлений, главное, чтобы это были сотрудники, умеющие предлагать и отстаивать новые идеи. Также в команду могут входить клиенты процесса.
Команда не должна быть слишком большой: оптимальное количество ее сотрудников 5-10 человек. Желательно, чтобы в команде были участники всех основных этапов процесса.
2.2.1.Пример «Сертификация». Формирование рабочей команды
Состав команды был подобран следующим образом:
Руководитель рабочей группы - Директор регионального отделения компании. На данном уровне выбора был однозначен, так как он являлся организатором всего процесса.
Специалист по сертификации - основной участник процесса, лучше всех знающий процесс и являющийся поставщиком информации для работы команды.
Начальник отдела закупок - руководитель подразделения, результаты деятельности которого непосредственно связаны с процессом.
Начальник отдела продаж - представитель подразделения потребителя процесса, деятельность которого напрямую связана с выполнением сертификации.
Специалист по информационным технологиям - основной генератор идей по совершенствованию процесса с помощью внедрения средств автоматизации.
Внешний консультант - представитель сторонней консалтинговой компании, передающий технологию проведения проекта по оптимизации бизнес-процесса.
Pasted from <http://www.regcons.ru/5-step%202-2.htm>
2.3. Выбор владельца процесса
Основные требования к владельцу бизнес-процесса:
• отвечать за результат процесса;
• умение организовывать и направлять работу проектной команды;
• умение продвигать решения среди равных руководителей в организационной иерархии;
• быть инициативным лидером, обладающим уважением и авторитетом в организации;
• хорошо знать процесс (при этом не обязательно, чтобы это был участник процесса);
• иметь полномочия и возможность изменять процесс;
• нести ответственность за ведение проекта по оптимизации бизнес-процесса.
В литературе по-разному называют руководителя бизнес-процесса, например: владелец процесса или хозяин процесса. Владельцем процесса обычно становится функциональный руководитель наиболее задействованного в процессе подразделения, но значительные изменения процесса легче проводить с владельцем, непосредственно не участвующим в процессе. Можно назначить владельцем процесса руководителя подразделения, использующего результаты процесса. Например, руководителем процесса "Разработка продукта" назначить начальника отдела продаж, непосредственно заинтересованного в удовлетворении требований потребителей и в дальнейшем отвечающего за продажи разрабатываемого продукта.
2.3.1. Пример «Сертификация». Выбор руководителя процесса
При первом взгляде на процесс логично было бы считать, что его владельцем будет назначен Специалист по сертификации, так он влиял на протекание всего процесса. Именно так чаще всего и происходит - владельцем процесса является специалист (или начальник подразделения), являющийся профильным при выполнении данного процесса. Однако, бывают исключения. Например, при выполнении процесса сертификации выяснилось, что специалист по сертификации, выполняя свои функциональные обязанности, определял лишь техническую сторону течения процесса, и при нормальном выполнении всех функций получение результатов процесса от него не зависело - он являлся лишь передаточным звеном между предприятием и Сертификационным центром, а будет получен сертификат или нет - зависело от других причин. Т.е., процесс протекает нормально, а продажи товара, лежащего на складе, так и не начинались. Это навело команду на мысль, что процесс сертификации, будучи формальной причиной «залеживания» товара на складе, являлся частью какого-то процесса более высокого уровня. Поскольку предприятие является торговым, его деятельность условно была разделена на две большие части - до продаж и собственно продажи. Понятие «до продаж» подразумевало комплекс процессов снабжения, результатом которых должна быть возможность продавать товар. Т.е., наличие товара на складе (формальная причина считать процесс снабжения завершенным) еще не означает, что его можно продавать, ибо он может «пролеживать», так как на него еще не получен сертификат. Поэтому владельцем процесса сертификации продукции назначили Начальника отдела закупок. Основной причиной назначения является указанная выше зависимость отдела закупок от процесса сертификации. Так как этот процесс не позволяет открыть товар в продажу, а, следовательно, товара нет для отдела продаж, отсутствие товара приводит к невыполнению функции закупки.
При определении места процесса в организации командой было принято решение о том, что Сертификация является частью закупки товаров. Во-первых, потому, что отсутствие сертификата, фактически, приводит к невыполнению функции снабжения, заканчивающейся передачей товара в отдел продаж. Во вторых, оптимизация складских запасов является задачей именно отдела закупок, а процесс Сертификации существенно влияет на задержки в хранении товара.
Pasted from <http://www.regcons.ru/5-step%202-3.htm>
2.4. Постановка целей процесса
Цель бизнес-процесса - это те результаты, которых мы намерены достигнуть, выполняя бизнес-процесс. Улучшения процесса при оптимизации должны способствовать достижению целей процесса за более короткие сроки либо с меньшими затратами ресурсов или с лучшим качеством. Кроме того, необходимо установить цели оптимизации в виде конкретных показателей, которых необходимо достичь в результате проведенной работы по изменению процесса.
Только поставив конкретные цели перед проведением оптимизации процесса, можно оценить результаты. Еще одним из критериев оценки, кроме стоимости, может выступать длительность выполнения процесса. Улучшение процессов может стать объединяющим звеном между повышением качества и снижением себестоимости. Один процесс может служить в организации для достижения нескольких целей, и наоборот, когда одна цель может достигаться несколькими процессами. При этом всегда нужно устанавливать критерии оценки достижения цели по анализируемому процессу, называющиеся ключевыми факторами успеха
Как уже было показано выше, цели компании - это цели верхнего уровня, которые образуют дерево целей. Цели нижнего уровня образуют цели бизнес-процессов, выполнение которых обеспечивает предприятию достижение целей верхнего уровня. Пример цели процесса снабжения: «Бесперебойное обеспечение производства качественными материалами и комплектующими по оптимальным транспортным потокам».
Критерии достижения цели:
1. наличие на складе требуемого производством ассортимента и количества продукции; минимальные транспортные расходы.
2. Целью оптимизации бизнес-процесса может быть: «Снижение транспортных расходов компании на 30% за счет оптимизации транспортных потоков и отсутствие простоев производства из-за нехватки материалов/ комплектующих».
Требования клиентов процесса отражаются через результат в целях процесса. Для этого необходимо проанализировать информацию о требованиях клиента и учесть ее при разработке целей процесса.
2.4.1.Пример «Сертификация». Клиенты и цели процесса
Требования к процессу Сертификации предъявляют четыре группы клиентов:
Потребители - предъявляют требования к качеству товаров компании и формальному подтверждению этого качества, т.е., наличию сертификата.
Руководство компании - предъявляет требования к бизнесу в целом и уменьшению величины оборотного капитала замороженного в складских остатках, на что существенно влияет процесс сертификации.
Отдел закупок - предъявляет требования к оборачиваемости товарных запасов и через них - к процессу сертификации.
Отдел продаж - заинтересован в поддержании полного ассортимента и, соответственно, быстрейшему открытию в продажу закупленных товаров
В качестве целей процесса сертификации были выбраны четыре цели, которые соответствуют требованиям различных групп клиентов процесса.
Только при достижении всех целей процесса и удовлетворении всех его потребителей можно считать процесс сертификации эффективным (разумеется, при выполнении требуемых показателей затрат финансовых, временных и иных ресурсов).
Pasted from <http://www.regcons.ru/5-step%202-4.htm>
2.5. Определение границ процесса, интерфейсов и требований клиентов
Прежде, чем начать работу по описанию процесса, необходимо обозначить участок, чтобы работа не стала бесконечной. Для этого определяются границы процесса, т.е. те рамки, за которые при описании заходить не будут, и зона ответственности.
Как правило, на старте любой работы должно произойти событие, дающее начальный толчок. Например, для начала обработки заказа менеджером по продажам необходим звонок клиента. Для выбранного процесса нужно определить, что будет являться запускающим событием, с которого начинается работа. Таких событий может быть несколько. В том же примере клиент может не только позвонить по телефону, но и отправить заказ по почте или факсимильной связи.
Если событий несколько, необходимо определить: происходят они одновременно и обязательно для каждого процесса, или достаточно какого-то одного для начала работ?
Если событие одно или несколько, но для начала процесса необходимо одно из них, логический оператор изменяется с «и» на «исключающее или».
После определения начальных событий необходимо определить: «Где закончится процесс?». Конечное событие также может быть не единственным. Например, успешным завершением процесса Приемки заказа может быть событие «заказ принят», но если клиента не устраивают предлагаемые нами товары / услуги, может произойти событие «клиент не заинтересован», и процесс для данного клиента на этом закончится.
После определения границ необходимо выделить все входящие и выходящие потоки (внешние интерфейсы). Сначала выделяются входящие потоки: информация, ресурсы. Затем определяются продукты/услуги, получаемые в результате процесса, и все виды информации. Особое внимание следует уделять документам, телефонным звонкам, продуктам/услугам используемому программному обеспечению.
После определения выходов процесса следует установить: «Кто использует полученные продукты/услуги или информацию (выходы процесса)?». Это будут клиенты процесса. Желательно провести опрос клиентов и выявить требования, предъявляемые к результатам процесса. Еще лучше, если это возможно, включить представителя клиентов в рабочую группу.
2.5.1.Пример «Сертификация». Определение границ процесса
Границей входа процесса будет получение отделом сертификации образцов товара и сопроводительной документации. При более внимательном рассмотрении процесса можно выделить еще одну входную границу процесса - это поступление недостающих документов от поставщика. В этом случае весь процесс сертификации начинается с самого начала.
Границей выхода будет оповещение отдела продаж о начале продаж товара. При неудачном завершении сертификации конечной границей процесса будет оповещение отдела закупок о некачественном товаре. Еще один случай возникает, если выявлена некомплектность документов, отправленных поставщиком. Тогда недостающие документы запрашиваются, и процесс сертификации продолжается.
После определения границ можно приступать к интерфейсам. Входным интерфейсом являются получаемые отделом сертификации сопроводительные документы и образцы, либо недостающие документы, досланные поставщиком.
Выходным интерфейсом будут оповещения либо отдела продаж о выпуске в продажу либо отдела закупок о некачественном товаре.
Клиенты
Основными клиентами процесса являются: потребители, руководство, отделы закупок и продаж. Требования клиентов к интерфейсам различны.
Внешние интерфейсы и требования клиентов.
Pasted from <http://www.regcons.ru/5-step%202-5.htm>
2.6. Описание бизнес-процесса
Описание бизнес-процесса состоит из следующих этапов.
Первым шагом будет составление обобщенной схемы процесса. На такой схеме приводится весь процесс в виде одного блока (функции) и обозначаются границы и внешние интерфейсы в виде событий (Рис. 42). В примере «Обработка запроса клиента» может начинаться с двух событий: «Пришел факс-заявка» и «Пришло эл. письмо-заявка». Завершиться этот процесс может тремя событиями: «Поставка невозможна», «Договор заключен» или «Клиент не платежеспособен». Владельцем процесса является Менеджер по продажам, входящим документом - заявка и исходящим - договор. Такая схема позволяет получить общее представление о процессе. В совокупности такие обобщенные процессы складываются в цепочку, начиная с поставщиков и заканчивая клиентами организации.
Следующее действие - определение функций / операций процесса. На данном шаге детализируется обобщенная схема. Необходимо сначала определить все действия, происходящие в процессе
Выделяя функции, необходимо стараться соблюдать однородность описания. Ориентироваться можно на объекты, над которыми производится работа. Если в процессе объектами являются заказ и договор, то не стоит использовать функции по вводу поля «Имя клиента», так как в этом случае мы опускаемся с уровня детализации «до документа» до уровня детализации «до полей документа».
Следующий шаг - это составление событийно-функциональной цепи.
Сначала необходимо расставить функции в последовательности их исполнения
Затем добавить события, поясняющие причины начала или поясняющие, чем заканчиваются операции. Добавление событий позволяет определить ветвления процесса, описать возможные повторения (циклы).
На данном этапе стоит задавать следующие вопросы:
1. Что приводит к началу выполнения данной операции?
2. Может ли данная операция начаться по другой причине?
3. Что выполняется после данной операции?
4. Какие еще могут возникнуть варианты продолжения процесса в зависимости от результата выполнения операции?
При ответах на подобные вопросы, как правило, выявляются операции, которые не были замечены при первом взгляде на процесс. Здесь важно учесть все варианты течения процесса, которые могут повлиять на достижение цели.
При составлении событийно-функциональных цепей необходимо задавать следующие вопросы для каждой функции (операции) процесса:
1. Какое действие выполняется?
2. Возможны ли другие варианты продолжения процесса?
3. Какая операция следующая?
4. Что может помешать течению процесса, и к чему это приведет?
Если создаваемая схема процесса становится слишком большой, неудобной в обращении и начинает плохо восприниматься, - значит необходимо разбить схему процесса на общую схему и детализации. Для создания общей схемы проведите анализ, из каких более крупных этапов состоит процесс или на какие подпроцессы можно разделить схему. В результате создайте обобщенную схему процесса и несколько схем детализаций.
Следующий шаг - определение исполнителей процесса и добавление их к схеме
Основные вопросы, по которым можно определить исполнителей:
1. Кто выполняет данную операцию?
2. Кто принимает решения?
3. Кто участвует в согласовании /утверждении результатов?
4. Кто должен быть информирован о выполнении / невыполнении?
5. К кому обращаются за консультацией в случае возникновения непредвиденных ситуаций?
Всех участников необходимо обозначить на схеме, определив тип участия в названии связи на диаграмме
Часто тип связи не показывается, понимая по умолчанию тип «Исполняет» . Также не показываются типы связей, которые логически следуют из названия функции или исполнителя. Например, клиенты - предъявляют требования к процессу, а функция «утверждение договора» подразумевает связь «утверждение».
Определить документы и ресурсы, используемые в процессе и отобразить их на схеме. Для определения документов и ресурсов следует задавать следующие вопросы:
1. Какие ресурсы необходимы для выполнения данной функции?
2. Какие документы требуются для выполнения?
3. В какие документы вносятся изменения в процессе выполнения функции?
4. Какие документы формируются в результате выполнения/не выполнения функции?
5. Как и какую дополнительную информацию исполнитель может получить в случае необходимости?
6. Кому передаются сформированные /откорректированные документы?
7. Каковы требования клиента к результатам (в данном случае под клиентом подразумевается потребитель результатов данной операции, а не всего процесса в целом, хотя в частном случае они могут совпадать)?
При описании информационных объектов (документы, файлы, папки, телефонные переговоры) необходимо указывать тип носителя (устройства передачи). Это будет иметь большое значение при анализе и дальнейшей автоматизации процесса.
2.6.1.Пример «Сертификация». Составление описания бизнес-процесса
Клиенты процесса детализируются в отдельной схеме. Это организационная схема, показывающая состав группы «Клиенты процесса сертификации».
На уровне обобщенных схем удобно состыковывать процессы верхнего уровня, чтобы конечное событие одного процесса являлось начальным событием следующего, и так - до момента выхода процесса за пределы компании.
Следующий шаг - определение функций процесса. В процессе сертификации было выделено 9 операций:
• Формирование комплекта для сертификации;
• Запрос недостающих документов от поставщика;
• Отправка недостающих документов;
• Доставка комплекта в Центр сертификации;
• Контроль качества. Принятие решения о выдаче сертификата;
• Доставка результатов сертификации;
• Информирование Отдела продаж о получении Сертификата;
• Оплата услуг Сертификационного центра;
Далее функции выстраиваются в последовательности их выполнения . После события «Сопроводительные документы и образцы переданы в отдел сертификации» следует функция «Формирование комплекта для сертификации». На данном этапе заполняется заявка на сертификацию и комплектуется коробка с образцами. При выполнении проверяется наличие всех документов, и при некомплектности (событие «Выявлена некомплектность документации») следует функция «Запрос недостающих документов от поставщика». В случае успешного выполнения комплектования следует событие «Комплект документации сформирован». События следуют за логическим оператором «исключающее или», показывающим, что возможно наступление либо одного, либо другого события, при этом исключается их одновременность. После успешного формирования пакета следует функция «Доставка пакета в центр сертификации». Затем непосредственно Сертификация - «Контроль качества и принятие 87 решения о сертификации» и доставка пакета обратно. После доставки возможны три ситуации:
• Получен отказ из-за некомплектности документации.
• Получен мотивированный отказ по несоответствию качества.
• Товар сертифицирован.
Может поступить только одно из этих событий, поэтому здесь также используется логический оператор «исключающее или». В первом случае следует запрос недостающей документации от поставщика. Во втором - следует функция «Оповещение отдела закупок о необходимости возврата товара». В третьем случае используется логический оператор «и», чтобы показать, что параллельно выполняются две функции: «Оплата услуг Сертификационного центра» и «Информирование отдела продаж о получении сертификата».
В результате к уже сформированной последовательности действий добавляем исполнителей . Специалист по сертификации выполняет функции:
• Формирование комплекта для сертификации;
• Запрос недостающих документов от поставщика;
• Информирование Отдела продаж о получении Сертификата:
• Оповещение отдела закупок о необходимости возврата товара.
В функции «Информирование Отдела продаж о получении сертификата» участвует Менеджер по продажам в качестве получающего информацию. Доставкой комплекта для сертификации в Центр и из Центра сертификации занимается курьер. Функцией «Оплата услуг Сертификационного центра» занимается бухгалтерия. Кроме этого, есть два внешних участника: Сертификационный центр, выполняющий функцию «Контроль качества. Принятие решения о выдаче сертификата» и Поставщик, занимающийся отправкой недостающих документов в случае некомплектности.
Добавляя используемые ресурсы, получаем полную детальную схему процесса . При выполнении функции «Формирование комплекта для сертификации» используются образцы и сопроводительная документация к товару, а в результате выполнения формируется Комплект для сертификации. В случае выявления недостающих документов формируется запрос на недостающую документацию. Входящими могут быть также Недостающие документы, отправленные поставщиком на соответствующий запрос. В функции доставки единственным входящим и исходящим ресурсом является Комплект для сертификации. Курьер забирает Комплект для сертификации из офиса и доставляет в Центр сертификации. При Контроле качества и принятии решения о выдаче сертификата входящим является доставленный Комплект, а исходящим - результаты сертификации в виде того же комплекта, но с заключением Сертификационного центра и сертификатом. Результаты доставляются курьером.
После доставки результата возможны три варианта, что отражено событиями:
• Получен отказ из-за некомплектности документации;
• Товар сертифицирован;
• Получен мотивированный отказ по несоответствию документации
В первом случае выполняется функция «Запрос недостающих документов от поставщика», где входящим документом является мотивированный отказ, а исходящим -запрос на недостающую документацию.
Во втором случае для оплаты услуг используются счета, входящие в комплект результатов сертификации, а для информирования отдела продаж используется полученный сертификат, также входящий в полученный комплект результатов сертификации. Информирование происходит по телефону, что отражено соответствующим обозначением исходящего телефонного звонка.
В третьем случае на основе поступивших результатов «Мотивированного отказа» уведомляется отдел закупок о необходимости уничтожения товара, это происходит также по телефону.
С прохождением всех этих этапов получается полная схема процесса. На данном этапе детализации уже можно согласовывать передаваемые ресурсы и используемые средства коммуникации.
Pasted from <http://www.regcons.ru/5-step%202-6.htm>
2.7. Анализ процесса и выработка рекомендаций
При проведении анализа необходимо придерживаться следующих шагов:
2.7.1.Выбор метода анализа, отвечающего целям процесса
Перед выполнением анализа выбранного процесса необходимо сначала вернуться к целям процесса - для чего он служит в организации, какие требования к нему предъявляют потребители результатов. Определив Цель процесса, нужно определить критерии ее оценки, т.е., когда мы сможем сказать, что цель достигнута. Это должны быть измеримые показатели или, как иногда говорят, «Критические факторы успеха». Именно по этим факторам выбираются в каждом конкретном случае необходимые виды анализа процесса. Не обязательно анализировать процесс всеми способами, это, скорее всего, приведет к излишней растрате ресурсов организации. Так, оптимизация стоимости процесса, составляющего 0.01% от оборота компании, будет ничтожна, даже если мы сократим затраты на 99.9%. При этом, возможно, сократив время выполнения этого процесса, мы добьемся куда больших, результатов, которые выразятся в повышении эффективности совсем других процессов. Большое значение для подобной работы имеет дерево целей компании и подвязанные к нему процессы, служащие достижению целей. С помощью такого инструмента можно понять место каждого процесса в организации и, соответственно, необходимость и методы работы с конкретным процессом. Чаще всего методы анализа определяются уже на этапе выбора процесса. Если целью работы с процессом является снижение затрат, то это будет стоимостной анализ. Если целью является повышение качества, то это будут методы контроля показателей качества на всех стадиях процесса. Если же нас интересует скорость обслуживания клиентов - это будет временной анализ.
Всеобщее применение имеют такие методы анализа, как исключение дублирования операций, выделение одного ответственного за все стадии процесса, уменьшение числа переходов с ручной обработки информации на автоматизированную и т.п.
2.7.2.Расстановка точек контроля в процессе
Точкой контроля в процессе является место, где будет проводиться измерение показателей. Точки контроля необходимы для сбора информации. Для того, чтобы проводить любой анализ, необходимо собрать информацию. В зависимости от проводимого анализа на одном и том же процессе могут быть разные точки контроля. Типичной точкой контроля является контроль готовой продукции на выявление брака. В процессе с помощью таких точек контроля могут отслеживаться маршруты движения документов, других ресурсов и продуктов.
2.7.3.Сбор информации о течении процесса
После выбора точек контроля необходимо определить период сбора данных и поставить задачу сотрудникам на сбор информации. Для этого необходимо разработать формы сбора информации и форматы формируемой отчетности
2.7.4. Проведение анализа и принятие решений по оптимизации
По выбранному методу проводится анализ полученной информации и делаются рекомендации по оптимизации процесса или принимается решение о проведении более детального анализа проблемных операций. Все оформляется в виде документа, описывающего исходную информацию, применяемый метод анализа и результаты. На основе анализа принимается решение об оптимизации процесса. Проводятся соответствующие организационные изменения и перестройка процесса, в т.ч., обучение персонала. Новые правила работ закрепляются регламентами. Составляется схема процесса «как надо» с учетом вносимых изменений.
2.7.5. Пример «Сертификация». Анализ процесса
Основная задача оптимизации данного процесса - сокращение его длительности. Для этого необходимо проанализировать возможные варианты исполнения процесса, рассчитать их продолжительность, и выявить возможные пути оптимизации.
Сценарий 1 - наименее продолжительный путь течения процесса. В этом случае выполняются следующие функции: «Формирование комплекта для сертификации» -«Доставка комплекта в Центр сертификации» - «Контроль качества. Принятие решения о выдаче сертификата» - «Доставка результатов сертификации» - «Информирование Отдела продаж о получении Сертификата».
При этом функция «Оплата услуг Сертификационного центра» не должна учитываться при измерении срока сертификации продукции потому, что после «Информирования Отдела продаж о получении Сертификата» товар выпускается в продажу и дальнейшее продолжение процесса не влияет на замораживание оборотных средств.
Сценарий 2 - приведенный в таблице, показывает такую же продолжительность процесса, как и оптимальный, но при этом не достигает цели. При получении мотивированного отказа из Центра сертификации следует оповещение отдела закупок о необходимости возврата товара. В итоге все убытки, понесенные в процессе закупки, доставки, хранения и, возможно, утилизации товара, необходимо взыскивать с поставщика. Это также, возможно, потребует времени и дополнительных затрат. Последовательность функций для этого сценария следующая: «Формирование комплекта для сертификации» - «Доставка комплекта в Центр сертификации» - «Контроль качества. Принятие решения о выдаче сертификата» - «Доставка результатов сертификации» -«Оповещение отдела закупок о необходимости возврата товара».
Сценарий 3 - самый продолжительный вариант из приведенных в таблице. Процесс, фактически, повторяется дважды: после получения результатов сертификации выясняется, что в сертификации отказано из-за несоответствия документации. Следовательно, необходимо запросить у поставщика недостающую документацию и после ее получения начинать процесс с формирования комплекта для сертификации. В результате повторение процесса приводит к резкому увеличению продолжительности - до 17 дней. Последовательность функций для этого сценария следующая: «Формирование комплекта для сертификации» - «Доставка комплекта в Центр сертификации» - «Контроль качества. Принятие решения о выдаче сертификата» - «Доставка результатов сертификации» - «Запрос недостающих документов от поставщика» - «Отправка недостающих документов» - «Формирование комплекта для сертификации» - «Доставка комплекта в Центр сертификации» - «Контроль качества. Принятие решения о выдаче сертификата» - «Доставка результатов сертификации» - «Информирование Отдела продаж о получении Сертификата».
Сценарий 4 - менее продолжительный, чем предыдущий, потому что здесь некомплектность документации выявляется на этапе формирования комплекта для сертификации. В результате только одна функция повторяется дважды (формирование комплекта для сертификации). Задержку же вызывает длительное получение недостающей документации у поставщика. В итоге продолжительность этого варианта процесса увеличивается до 12 суток. Последовательность функций для этого сценария следующая: «Формирование комплекта для сертификации» - «Запрос недостающих документов от поставщика» - «Отправка недостающих документов» - «Формирование комплекта для сертификации» - «Доставка комплекта в Центр сертификации» - «Контроль качества. Принятие решения о выдаче сертификата» - «Доставка результатов сертификации» -«Информирование Отдела продаж о получении Сертификата»
2.7.6.Пример «Сертификация». Выводы и рекомендации
Представленные данные показывают, что наибольшая задержка происходит при возвращении товара из-за несоответствия документации и в дальнейшем - после запроса и получения документации от поставщика повторной сертификации. Длительность такого процесса равна 17 суткам, что превышает длительность оптимального варианта почти в 3 раза. В данном процессе необходимо усилить предварительный контроль за комплектностью документов, отправляемых на сертификацию, чтобы избежать повторной сертификации (вариант 3). Еще больший эффект может быть достигнут при формулировании требований к поставщикам в виде анкеты, заполняя которую при отправке, поставщики будут сразу проверять комплектность документации. В этом случае есть возможность избежать задержек, возникающих в варианте 4, а это еще дополнительные 6 дней (продолжительность варианта 4 - продолжительность варианта 1 = 12 дней - б дней).
Pasted from <http://www.regcons.ru/5-step%202-7.htm>
2.9. Внедрение предложений
Решающее значение на данном этапе приобретает поддержка проекта руководителями, принимающими решения, так как проект часто затрагивает полномочия сотрудников, участвующих в процессе. Кроме этого, важную роль имеет коммуникация со всеми подразделениями, затрагиваемыми проектом.
Если они не информированы, может возникнуть сильное сопротивление изменениям, способное остановить проект или сделать невозможной работу внедряемой системы.
Внедрение предложений лучше всего проводить как отдельный проект - с назначением ответственного, планированием этапов работ по внедрению и технико-экономическим обоснованием. Необходимо планировать привлечение сотрудников предприятия для реализации подобной работы.
Во-первых, у привлекаемых сотрудников должна быть снижена загрузка по основной деятельности, а во-вторых, такая работа должна оплачиваться. Вели этого не предусмотреть, проект придется вести 1-2 энтузиастам, не рассчитывая на какую-то помощь, а. скорее, сталкиваясь с сопротивлением.
Далее, для закрепления проделанных шагов, приводится еще один комплексный пример работы с процессом. Это будет процесс заключения договоров.
Pasted from <http://www.regcons.ru/5-step%202-9.htm>
2.10. Пример. Оптимизация процесса «Заключение договоров»
2.10.1.Описание ситуации
Существующий в крупной компании процесс заключения договоров затягивается до двух недель из-за большого количества согласований. В результате часто срываются сделки на этапе заключения договора с поставщиком. Процесс включает множество участников, принимающих решения в своей области, касающиеся договоров. Необходимо провести оптимизацию процесса, сократив его продолжительность
2.10.2.Этапы работы с процессом
2.10.2.1. Границы и интерфейсы процесса, требования клиентов. Обобщенная схема процесса
Границы процесса:
• Процесс начинается с получения отделом закупок утвержденной годовой заявки на материально-техническое обеспечение.
• Процесс завершается подписанием договора с поставщиком.
• Сведения об интерфейсах, клиентах и требованиях
Для исключения варианта 2 необходимо проводить тщательный отбор поставщиков. В случае прохождения процесса по сценарию 2 вообще не достигаются цели процесса, и компания несет убытки.
Рекомендации.
Сценарий 1 является оптимальным, и необходимо стремиться, чтобы все процессы сертификации осуществлялись по этой схеме.
Сценарий 2. Необходимо исключить, внедрив систему, предусматривающую отказ от работы с поставщиками некачественной продукции.
Сценарий 3. Необходимо исключить, усилив контроль над комплектностью документации. Разработать перечень необходимой документации для сверки.
Сценарий 4. Разработать стратегию работы с поставщиками и включить требования к документации в договора. В будущем постараться исключить и этот вариант процесса.
Документирование процесса
Примерная структура положения о процессе приведена ниже:
1. Общие положения
2. Спецификация процесса
2.1. Назначение процесса. Владелец процесса. Границы и внешние интерфейсы процесса. Клиенты процесса
2.2. Цели процесса
2.3. Объекты, используемые для описания бизнес-процесса
2.4. Описание процесса
2.5. Параметры и показатели процесса
2.10.2.2. Цели процесса
Обеспечение поставки материалов и комплектующих от нужного поставщика в согласованные сроки с качеством, соответствующим требованиям клиента (Заявителя).
2.10.2.3. Выбор Владельца процесса и формирование рабочей команды
Владельцем процесса назначается Начальник отдела МТС. Решающим критерием для выбора владельца явились его возможность влиять на процесс, а также на результаты и необходимую исходную информацию (так как он руководит составлением Сводной годовой заявки на МТС).
В команду вошли:
• Владелец процесса
• Администратор компьютерного парка •
Начальник отдела развития
• Менеджер по снабжению
2.10.2.4. Описание процесса с использованием программного продукта ARIS Toolset
На Рис.56 приведена детальная схема процесса заключения договоров «как есть». В процессе «как есть» существует 7 согласований, которые проходят все договора без исключения. В согласованиях участвуют почти все отделы:
• Отдел МТС - Директор по МТС, Начальник отдела, Специалист отдела МТС.
• Финансово-экономический отдел - Начальник финансового отдела.
• Бухгалтерия - Главный бухгалтер.
• Юридический отдел - Юрист.
• Технический отдел - Главный инженер.
• Служба безопасности - Директор по безопасности.
2.10.2.5. Анализ процесса
Основной задачей при анализе процесса заключения договоров является устранение бюрократической волокиты, а соответственно, сокращение продолжительности процесса. При этом необходимо повысить качество заключаемых договоров через исключение повторяющихся ошибок
Для решения этих задач подходят следующие методы анализа:
• метод устранения ненужных операций:
• параллельное выполнение согласований;
• разделение договоров на типы с различными сценариями прохождения согласований для каждого типа договоров. Критерием разделения на типы может служить стоимость.
• уменьшение количества согласований для плановых договоров и усложнение процедуры прохождения внеплановых - для улучшения финансовой дисциплины;
• типизация форм договоров
Следующие предложения были внесены Начальником отдела развития:
1. Вместо всех согласований ввести проверку на соответствие плану и утверждение.
2. Подписание всех договоров топ-менеджерами не обязательно, поэтому имеет смысл разделить договора на несколько групп:
• договора до 50 000 руб.
• договора от 50 000 до 200 000 руб.
• договора от 200 000 до 1 000 000 руб.
• договора свыше 1 000 000 руб.
3. В зависимости от принадлежности договора к той или иной группе договор будет подписываться на своем уровне.
4. Исключение согласования с юристом в случае использования типовых договоров при условии, что контрагент не вносит изменений в договор. Передача функции «Отправка договора поставщику» Специалисту отдела МТС. Анализом процесса с точки зрения возможностей автоматизации занимался Администратор компьютерного парка и сделал следующие предложения:
5. Внедрение единой информационной системы учета документов и службы МТС с возможностью параллельного согласования, проводимого в автоматизированной информационной системе с использованием электронной подписи.
Рекомендации
Необходимо внедрение новой схемы процесса Заключения договора «Как надо». Для этого следует провести следующие мероприятия:
1. Разработать общие требования к автоматизированной системе документооборота, поддерживающей параллельное согласование и перенаправление договоров в зависимости от условий участникам процесса. Как минимум, должна быть возможность маршрутизации в зависимости от суммы договора и от параметра типовой/нети повой.
2. Разработать общий регламент прохождения договоров.
3. Исключить ручное заполнение договора и заменить его заполнением в ИС.
4. Объединить функции «Заполнение договора» и «Отправка поставщику» для уменьшения времени на передачу документа.
5. Ввести типовые формы договоров и исключить для типовых договоров согласование юристом.
6. Внедрить автоматизированную систему параллельного (одновременного) согласования для внеплановых договоров.
7. Включить в регламент и настроить в автоматизированной системе правила утверждения договоров в зависимости от суммы.
Заключение
По приведенным примерам видно, что не всегда работа с процессом приводит к изменению схемы процесса. В случае с сертификацией продукции изменения схемы процесса не произошло, но возникли требования к методам работы. Наоборот, в процессе «Заключение договора» произошло изменение процесса, причем схема его внешне усложнилась. Однотипные варианты оптимизации встречаются редко. Даже в компаниях с однотипными процессами команды, скорее всего, разработают различные предложения по оптимизации. Главное в процессе работы - не забывать о целях ее проведения и не составлять описаний бизнес-процессов ради них самих. Процессная методология содержит колоссальные возможности для развития бизнеса, нужно только научиться ее применять. Успехов Вам на пути бизнес-инжиниринга!
Pasted from <http://www.regcons.ru/5-step%202-10.htm>
| Формат описания бизнес-процессов |
Преимущества
|
Недостатки
|
| Текстовый | Простота, нет необходимости в обучении | Низкая степень формализации, плохая структурированность |
| Табличный | Хорошая структурированность | Слабые возможности для отражения ветвлений процесса |
| Графический | Наглядность, наилучшее восприятие | Необходимость обучения использованию формата |
| № | Наименование функции | Исполнитель | Ресурсы (в т.ч. документы, программы) |
| Входящие | Исходящие |
| № |
Функция
|
Исполнитель
|
| 1. | Оформление договора | Менеджер по закупкам |
| 2. | Согласование договора | Юрист |
| 3. | Согласование договора | Начальник отдела закупок |
| 4. | Согласование договора | Главный бухгалтер |
| 5. | Согласование договора | Коммерческий директор |
| 6. | Согласование договора | Гл. инженер |
| 7. | Утверждение договора | Генеральный директор |
| Фирма-разработчик |
Optima, Россия
|
Staffware pic, Great Britain
|
«Весть -Мета Технология», Россия
|
Инталев, Россия
|
|
| Наименование системы |
Optima-WorkFlow
|
Staffware 97
|
WorkRoute
|
Инталев: Бизнес-процессы
|
|
| Стоимость за 1 клиентское место, $ США |
80
|
770
|
300
|
240-3840 Неограниченное количество пользователей
|
|
| Архитектура системы |
Клиент-сервер
|
Клиент-сервер
|
Клиент-сервер
|
Клиент-сервер/файл сервер
|
|
| WEB-технология |
Да
|
Да
|
Да
|
Да (при условии наличия 1C:WEB)
|
|
| Защита данных в системе | |||||
| Стандарт защиты информации |
1В (сертификат Гостехкомиссии №96)
|
Да
|
Да
|
Нет
(определяется форматом хранения данных)
|
|
| Сертифицированно е шифрование |
Да (Россия, ФАПСИ
лицензия № 107)
|
Да
|
Да
|
Нет
|
|
| Сертифицированна я электронно-цифровая подпись |
Да (Россия, ФАПСИ
лицензия № 107)
|
Да
|
Да
|
Нет
|
|
| Управление потоками работ | |||||
| Жесткая маршрутизация |
Да
|
Да
|
Да
|
Да
|
|
| Свободная маршрутизация |
Да
|
Да
|
Да
|
Да
|
|
| Автоматич. отправка документов по маршруту |
Да
|
Да
|
Да
|
Да
|
|
| Редактор маршрутных схем |
Да Графический
|
Да Графический
|
Да Графический
|
Да Графический
|
|
| Описание параметров технологических этапов |
Да
|
Да
|
Да
|
Да
|
|
| Формирование календаря рабочего времени |
Да
|
Да
|
Да
|
Нет
|
|
| Обеспечение документооборота | |||||
| Поддержка отечественной схемы документооборота |
Да
|
Нет
|
Да
|
Да
|
|
| Поддержка западной схемы документооборота |
Да
|
Да
|
Да
|
Да
|
|
| Хранение всех версий документов |
Да
|
Да
|
Да
|
Нет
|
|
| Контроль версий документов |
Да
|
Да
|
Да
|
Нет
|
|
| История обработки документов |
Да
|
Да
|
Да
|
Да
|
|
| Регистрация документов (картотека) |
Да
|
Да
|
Да
|
Да
|
|
| Редактор регистрационных карточек |
Да Графический
|
Да
|
Да
|
Да
|
|
| Поиск документов по атрибутам регистр, карточек |
Да
|
Да
|
Да
|
Да
|
|
| Контроль потоков работ и документов | |||||
| Возможность задания нормативных значений |
Да
|
Да
|
Да
|
Да
|
| Возможность постановки/снятия с Контроля |
Да
|
Да
|
Да
|
Да
|
| Контроль сроков выполнения |
Да (в минутах)
|
Да (в минутах)
|
Да (в минутах)
|
Да (в минутах)
|
| Контроль работы исполнителей |
Да
|
Да
|
Да
|
Да
|
| Уведомление о постановке на контроль |
Да
|
Да
|
Да
|
Да
|
| Уведомление о выполнении этапа |
Да
|
Да
|
Да
|
Да
|
| Напоминание об истечении сроков исполнения |
Да
|
Да
|
Да
|
Да
|
| Резолюции |
Да
|
Да
|
Да
|
Да
|
| Отчетность | ||||
| Развитая отчетность |
Да
|
Да
|
Да
|
Да
|
| Статистический анализ |
Да
|
Да
|
Да
|
Да
|
| Администрирование системы | ||||
| Определение прав доступа пользователей |
Да
|
Да
|
Да
|
Да
|
| Регистрация событий в системном журнале |
Да
|
Да
|
Да
|
Да
|
| Совместимость с программными системами | ||||
| Совместимость с программными продуктами |
MS Word, Excel, Access, PowerPoint, CorelDraw, PageMaker, MS
|
MS Word, Excel, Access, PowerPoint, CorelDraw
|
MS Word, Excel, Access, PowerPoint, CorelDraw, PageMaker,
|
1С; MS Word, Excel, внешняя почта, запуск произвольных файлов в
|
Outlook, MS
|
MS Outlook,
|
ассоциированной
|
||
Proj ect, WordPad
|
MS Project,
|
программе
|
||
WordPad
|
||||
| Операционная |
Windows
|
Windows NT
|
Windows
|
Windows
|
| система |
95/98/NT
|
4.0ШМ
|
95/98/NT
|
98/ME/NT/2000/X
|
4.0/2000/XP
|
OS/2
|
4.0/2000/XP
|
P
|
|
| База данных |
ODBC-стандарт
|
ODBC-
|
ODBC-
|
1С (SQL, DBF)
|
(MS Exchange
|
стандарт
|
стандарт (MS
|
||
Server, MS SQL
|
(MS SQL
|
SQL Server,
|
||
Server,
|
Server,
|
ORACLE,
|
||
ORACLE,
|
ORACLE,
|
Informix,
|
||
Informix,
|
Informix,
|
SyBase}
|
||
SyBase)
|
SyBase)
|
Цели
|
Клиенты
|
| Обеспечение стандартного качества фармацевтических товаров и услуг, предоставляемых клиентам | Потребители |
| Уменьшение величины оборотного капитала замороженного в складских остатках | Руководство; |
| Ускорение оборачиваемости товарных запасов | Отдел закупок; |
| Обеспечение возможности быстрейшего «открытия» товара в продажу. Получение сертификата | Отдел продаж |
| Внешние интерфейсы процесса | Сопроводительные документы и образцы, передаваемые в отдел сертификации; Недостающие документы, отправленные поставщиком; Оповещение отдела закупок о некачественном товаре для дальнейшего возврата/уничтожения; Оповещение отдела продаж об открытии товара в продажу. |
| Клиенты процесса «С ертиф икация» | Потребители; Руководство; Отдел закупок; Отдел продаж |
| Требования клиентов процесса | Потребители: Соответствие качества продукции установленным государственным стандартам, гарантирующее безопасность для здоровья и подтверждаемое наличием сертификата. Руководство: Минимизация сроков проведения сертификации для ускорения оборачиваемости товаров. Отдел закупок: Получение полного комплекта документов необходимых для Сертификации от поставщика. Отдел продаж: своевременное извещение по телефону о получении сертификата, свидетельствующего о возможности открытия товара в продажу. |
