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

Рисунок 6. Иллюстрация процессного подхода

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

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

Что ожидаем в итоге

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

Рисунок 7. Диалоговое окно, конечно, придуманное. Но разве это не намек на идеальное решение?

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

Оценка потребности в ресурсах

Если вам ранее доводилось заниматься подобной деятельностью – то вы уже представляете себе, насколько облегчит проектирование Ваш расчетный счет, скольких сотрудников вы временно потеряете, как полноценные боевые единицы (и скольких вообще потеряете). Рассуждения ниже скорее для тех, кто впервые планирует приступать к такой работе – ведь опасно как переоценить, так и недооценить масштабы грядущих потерь. Завышенная оценка сложности может привести к отказу от проекта вообще (вместе с надеждами стать лидером отрасли), либо к излишне высоким суммам по договору с исполнителем. Заниженная оценка приведет к тому, что в какой-то момент ресурсов не хватит и проект будет заброшен – что снова означает потерянные деньги. Временная оценка не менее важна – и по тем же соображениям. Практика показывает, что компании среднего размера – от 500 до 1000 человек – разрабатывают и внедряют новую систему управления целиком  за один год. Компаниям с 10 тыс. сотрудников потребуется примерно 2-3 года. Впрочем, в зависимости от сложности ситуации, время внедрения может увеличиться и в два и в три раза. 

Из потребности в людских ресурсах можно предположить на весь этот период постоянную команду из 3-4 человек (стратег, аналитики) и необходимость привлечения к работе сотрудников предприятия по мере необходимости – начальников подразделений и рядовых исполнителей. Начальники будут привлекаться, приблизительно на один-два месяца чистого времени на протяжении всего цикла проектирования и внедрения, рядовые исполнители – меньше, от 2 недель до месяца. Затраты на своих специалистов, учитывая это время, можно оценить. Внешние консультанты стоят недешево. Услуги специалиста могут обойтись от 1,5 до 25 тыс. рублей за час работы. 

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

Вопрос: Можно ли снизить затраты на проектирование системы управления? 

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

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

                    Вторая причина берет исток в понимании основ эффективности. Часто повторяющиеся процессы являются критичными для общего хода дела – ведь, несмотря на простоту и шаблонность, их вклад в общие трудозатраты весьма значителен. В проектировании бизнес-процессов достаточно много шаблонных, повторяющихся действий, которые, при ручной работе, заберут львиную долю всего времени разработки. Конечно, применение методик CTRL-C – CTRL-V заметно облегчает работу в WORD или Excel при их вводе, однако специализированное ПО предоставляет еще более удобную среду для проектирования.

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

                    Четвертая причина – возможность оптимизации. Пусть на сегодняшний день и не существует программы, способной самостоятельно спроектировать оптимальный вариант бизнес-процесса (иначе и необходимость в руководителях и бизнес-аналитиках отпала бы сама собой, компьютер дешевле) – но произвести симуляцию сотен циклов прохождения каждого из тысяч бизнес-процессов в десятках вариаций их взаимодействия… Попробуйте проделать это с помощью Excel! А без статистической обработки в данном случае не обойтись – ведь система будет работать в реальном мире, где всякое случается.

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

Рисунок 8. Большое количество регламентов не так просто состыковать… Если не пользоваться автоматизированной системой моделирования.

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

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

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

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

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

[1] Ковалев С. М., Ковалев В. М. Технология структуризации и описание организации – шаг за шагом  //Консультант директора №8 (212), Апрель, 2009 г.

[2] Плотникова Н.И. Комплексная автоматизация туристского бизнеса. 4.1. Информационные технологии в сфере гостеприимства: учебно-мето­дическое пособие. М.: Советский спорт, 2010.

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

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

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

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

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

          Моделирование бизнес процессов играет огромную роль в управлении бизнес процессами. Необходимо отметить, что в английском переводе оба вида деятельности имеют одинаковую аббревиатуру BPM (Business Process Modeling и Business Process Management, соответственно), что часто приводит к путанице. Данный факт необходимо учитывать т.к. большинство литературы по данному предмету на английском языке. Графическое описание бизнес-процессов и их имитация это методы анализа бизнес-процессов, эффективность которых доказана многолетней практикой использования и многочисленными исследованиями. Для графического представления бизнес процессов используются различные языки, но наиболее популярными и подходящими считаются UML и Business Process Modeling Notation.

          Моделирование и имитация бизнес процессов являются ключевыми методами для реинжиниринга бизнес-процессов (Business Process Reengineering) и использования методологий непрерывного улучшения бизнес-процессов, например, такими как Six-Sigma.

По каким критериям необходимо выбирать BPMS?

                    Аналитики компании Gartner предлагают обратить внимание на следующие требования при выборе BPM-системы:

                    поддержка задач «человек-человек» и удобство интерфейса пользователя;

                    поддержка организационной структуры и ролевых групп;

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

                    возможность управления логикой процесса с рабочего места пользователя;

                    удобство использования и администрирования;

                    присутствие графических средств разработки моделей бизнес-процесса;

                    поддерживаемые архитектуры и стандарты;

                    производительность и масштабируемость;

                    способность обслуживать многочисленные, продолжительные и распределённые процессы;

                    понятный интерфейс настройки и возможность минимального участия ИТ-специалистов во внедрении и поддержке;

                    возможность информирования в реальном времени по отклонениям показателей процесса;

                    поддержка сервис- ориентированной архитектуры (SOA — Service Oriented Architecture);

                    присутствие шаблонов бизнес-процессов, на основании которых могут быть разработаны новые процессы;

                    невысокая совокупная стоимость владения.

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

В такой ситуации:

                    Никто не отвечает за процесс в целом и его результаты;

                    Такой процесс подвержен сбоям, так как многие работники вынуждены действовать независимо друг от друга;

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

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

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

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

Описание бизнес-процесса. Способы описания бизнес-процессов:

                    Текстовое описание

                    Графическое представление процесса, например в виде диаграмм

                    Смешанный вариант (диаграммы + текстовые пояснения)

Для создания такого описания необходимо ответить на вопросы:

                    Кто потребитель БП и что служит выходом бизнес-процесса

                    Кто поставщик БП и что служит входом бизнес-процесса

                    Какие требования предъявляются к выходам и входам этого БП

                    Каковы операции, входящие в состав этого БП.

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

Процессная модель предприятия должна строиться с учетом следующих положений:

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

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

                    На следующем уровне деятельность должна быть детализирована на процессы.

                    Далее, процессы детализируются посредством функций.

                    И на последнем уровне описание функций осуществляется с помощью миниспецификаций.

                    Процессные потоковые модели отвечают на вопросы: ЧТО? – КОГДА? – КТО? – КАК? – КОМУ?

Методы проведения обследования предприятия. Основные методы:

1.                    Анкетирование – в основном применяется к руководителям подразделений. С помощью анкет собирается следующая информация:

2.                    ФИО руководителя подразделения, телефон;

3.                    координаты контактного лица (к кому в отсутствие или при занятости руководителя можно обращаться);

4.                    каковы (с позиций Вашего подразделения) должны быть цели создания интегрированной системы управления предприятием;

5.                    основные функции подразделения;

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

7.                    какая информация передается в другие подразделения;

8.                    какая информация формируется в подразделении;

9.                    с какими внешними предприятиями (банк, заказчик, поставщик и т.п.) взаимодействует подразделение и какой информацией обменивается;

10.                 физическое представление информационных потоков и хранилищ (документ, сеть, журнал, картотека и т.п.);

11.                 период хранения информации;

12.                 документы от и для руководства;

13.                 штатная структура и квалификация кадров;

14.                 техническое оснащение подразделения (компьютеры, сеть, модем и т.п.);

15.                 используемые программные продукты;

16.                 подпись.

17.                 Сбор и анализ документов – результатом этого этапа должен стать альбом форм с разбивкой по видам деятельности (в каждом виде деятельности может быть определена дополнительно внутренняя классификация документов по отдельным признакам).

18.                 Интервьюирование – должно дать ответы на следующие вопросы:

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

20.                 Детальная информация о реальных технологиях работы предприятия и его подразделений (нормативно-справочная информация не всегда полно описывает эти технологии);

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

22.                 Должны быть специфированы все информационные хранилища, в том числе и бумажные;

23.                 Детальная информация об аппаратно-технической и телекоммуникационной базе предприятия;

24.                 Статистические данные по бизнес-процессам предприятия.

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

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

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

Необходимость

совершенствования

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

привела

к

созданию

методологии управления процессами (МУП), которая включает шесть основных шагов:

Шаг 1.

Определение владельца(ев) процесса

Шаг 2.

Описание границ и интерфейсов процесса

Шаг 3.

Описание самого процесса с помощью программного инструментария

Шаг 4.

Установка точек контроля за процессом

Шаг 5.

Измерение показателей процесса в точках контроля

Шаг 6.

Анализ полученной информации и предложения по совершенствованию

КАК РАЗРАБАТЫВАЕТСЯ СИСТЕМА БИЗНЕС – ПРОЦЕССОВ.
Бизнес-процесс представляет собой систему последовательных, целенаправленных и регламентированных видов деятельности, в которой посредством управляющего воздействия и с помощью ресурсов входы процесса преобразуются в выходы, результаты процесса, представляющие ценность для потребителей (А.Г. Шугаев). Ключевыми свойствами бизнес-процесса является то, что это конечная и взаимосвязанная совокупность действий, определяемая отношениями, мотивами, ограничениями и ресурсами внутри конечного множества субъектов и объектов, объединяющихся в систему ради общих интересов с целью получения конкретного результата, отчуждаемого или потребляемого самой системой.
Система бизнес – процессов устанавливает, какой комплекс ключевых действий нужно совершить, чтобы добиться достижения стратегических целей.
Система бизнес – процессов служит фундаментом для определения потребностей в компетенциях, квалификации кадров, численности, в материальных и нематериальных ресурсах, инфраструктуре для реализации стратегии.
На основании стратегии и тактики производим проектирование (инжиниринг) бизнес – процессов, то есть, устанавливаем - какие основные процессы необходимы по потребителю, товару, рынку в разрезе функций управления: маркетинг, производство, сбыт, управление, какие обеспечивающие процессы необходимы для осуществления общей деятельности.
Инжиниринг (англ. engineering, лат. ingenium) — изобретательность; выдумка; знания. Инжиниринг — это набор приемов и методов, которые компания использует для проектирования бизнеса в соответствии со своими целями.
Инжиниринг бизнес – процессов подразумевает: 
1. Анализ деятельности (разделение) по составляющим процессам и операциям.
2. Технологию процессов – последовательность операций в процессах. 
3. Необходимые ресурсы для выполнения процессов. Проектирование системы ресурсов.
4. Синтез процессов (взаимодействие) в общие результаты: балансировка, узкие места, синергия.
5. Содержание труда в процессах: сложность, трудоемкость.
6. Производительность процесса. Факторы, влияющие на производительность.
7. Показатели результативности процессов.
Инжиниринг отражается в форме модели (моделирование системы процессов) при запуске деятельности, изменениях в деятельности, внедрении новых видов деятельности. 
Реинжиниринг осуществляется по периодам времени, в случаях снижения показателей, изменения стратегии, внедрения инноваций и других случаях.
Критерии выделения бизнес – процессов:
1. Направленность на цели. 
2. Продукт (внешний или внутренний) - результат выполнения процесса.
3. Прямое или косвенное участие в доходах.
4. Технологическая необходимость, от процесса нельзя отказаться.
Свойства бизнес – процессов:
• Причинно – следственные связи.
• Альтернативность в выполнении, способах, средствах выполнения.
• Производительность (количество).
• Качество.
• Сложность.
• Трудоемкость.
• Повторяемость.
• Конкурентные преимущества.

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



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

2 этап – разработка действий по выполнению задач. 
Из поставленных задач вытекают действия – процессы, которые необходимы для их решения. 
Процессы проектируются с учетом критериев и свойств, направлены на решение задач в разрезе управленческих стратегий: маркетинг, разработка и производство, сбыт, управление деятельностью. Проектирование осуществляется на основе технологий с выделением составляющих операций (последовательно и параллельно выполняемых), обеспечивающих продуктивность деятельности. Технологии могут использоваться, как собственной разработки, так и заимствованные. Оценка применяемых технологий производится по критериям:
1. Уровень к мировым достижениям.
2. Прогрессивность – способность к развитию, модернизации, реинжинирингу.
3. Соответствие стратегии и тактике.
4. Оптимальность к возможностям: стоимость, компетенции, риски, финансирование и другие.
5. Непротиворечивость другим бизнес процессам, соответствие принципу МЕСЕ - аббревиатура от Mutually Exclusive, Collectively Exhaustive— «взаимно исключающие, совместно исчерпывающие».
После выбора технологий бизнес – процессов осуществляется их синтез в общую систему для обеспечения синергии усилий. Искусство синтеза состоит в создании системы, обеспечивающей необходимую производительность (определяется наиболее узкими местами), качество, взаимодействие и взаимодополнение отдельных бизнес – процессов для выполнения задач. Искусство проектирования бизнес – процессов требует высокой компетенции и квалификации специалистов его осуществляющих, периодического анализа и аудита, так как во многом определяет результативность и эффективность деятельности.
«Успех – это несколько правильных действий, повторяемых ежедневно, а неуспех – набор неправильных действий, повторяемых ежедневно (Джим Рон).

3 этап – определение результативности бизнес – процессов. 
«Вы не можете управлять тем, что не можете оценить» (В. Хьюлетт, основатель компании Hewlett Packard).
Спроектировать бизнес – процессы недостаточно, нужно ими управлять в дальнейшем для оценки их результативности и эффективности, иначе они могут тормозить развитие, сводить на нет даже гениальные решения, поэтому необходимо постоянно измерять и оценивать их результативность и эффективность. Измерение и оценка производятся посредством показателей.
Таблица общих показателей результативности и эффективности бизнес – процессов.



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

4этап – установление способов осуществления процессов, порядка совершенствования, внедрения инноваций.
Для каждого бизнес – процесса следует на основании экспертных оценок, анализа внешней среды разработать способы осуществления. Разработка способов подразумевает:
1. Выбор приемов и методов труда.
2. Выбор степени автоматизации.
3. Установление уровня стандартизации, сертификации.
4. Определение потребности в материалах, средствах производства, использования нематериальных активов, условий труда и других факторах.
5. Проведение мониторинга по инновациям в процессе.
6. Установление порядка изучения инноваций и их внедрения.
Анализ бизнес – процессов:
1. Значимость процесса: ключевой, обычный. Роль процесса в результате (доходе).
2. Сколько процесс может произвести результата (производительность).
3. Сколько процесс стоит (себестоимость + финансовые издержки по пассивам).
4. Кто оплачивает – потребитель, изготовитель.
5. Зачем процесс нужен, можно ли обойтись без него. Да, нет - последствия.
6. Есть ли альтернативы в реализации процесса: сами, аутсорсинг, другие.
7. Можно ли сократить издержки (автоматизация, технологии, приемы труда и другие).
8. С какими процессами взаимодействует: от каких зависит, какие зависят от него, как взаимодействуют, как синергия.
9. Результат процесса – в чем продукт (внешний и внутренний).
10. Эффективность процесса – результат минус затраты, выгоды, польза.
11. Перспективы процесса: разработка ноу – хау, инноваций и т.д.
12. Оснащенность процесса.
13. Сложность – квалификация.
14. Качество: уровень, брак, конкуренция.
15. Какие ресурсы обеспечивают бизнес – процесс.

5 этап – утверждение системы бизнес – процессов.
Система утверждается в установленном порядке и обязательна к применению и исполнению.
После утверждения системы процессов, она служит основанием для структурирования деятельности по составляющим направлениям деятельности, расчета ресурсов, подбора кадров, внедрения системы качества. 
Осуществление бизнес – процессов претворяется в практику посредством систем управления: планирование, информация, измерение, контроль, анализ, мотивация. Каждый процесс должен поддерживаться функциональным обслуживанием: техническим, юридическим, экономическим, финансовым и другими. 
В организации бизнес – процессов часто увлекаются формальной стороной, а не содержательной. Инжиниринг бизнес – процессов состоит в творческом анализе необходимых действий для технологичности, оптимизации затрат ресурсов, трудоемкости, производительности, качества. Красивые картинки в программных средствах служат для изложения сути, а не украшения деятельности для себя или инвесторов и не могут заменить настоящий инжиниринг. 
Бизнес – процессы часто бывают излишними, вызывающимися из-за амбиций бюрократии, которые удовлетворяют личным интересам, а не интересам дела, а значит, ведут к повышенным издержкам при низком результате. Если процессы соответствуют стратегии и тактике управления, основываются на организационных задачах и показателях результативности и эффективности, то вероятность лишних действий значительно менее вероятна. 
Особенность бизнеса в необходимости не только проектировать, выстраивать бизнес – процессы, но делать их гибкими. Проектирование позволяет применять автоматизацию, но при этом нужно понимать, что автоматизация, внедрение информационных технологий – это средства для повышения продуктивности бизнес – процессов, а не самоцель.
«Автоматизация беспорядка приводит к автоматизированному беспорядку» (Чампи, Хаммер).
Стремясь повысить эффективность своей фирмы, руководство часто не понимает, что улучшение отдельных звеньев процесса не решит общей проблемы – наоборот, это лучший способ гарантировать плохую эффективность и в дальнейшем. Множество компаний пытается наладить отдельные этапы работы вместо перестройки всего ее процесса.
Теперь компании должны быть организованы на основе ключевых процессов. Именно поэтому организация должна начинаться с бизнес – процессов.
Нужен периодический реинжиниринг бизнес – процессов. Когда?
По результатам периодического организационного аудита, при снижении показателей деятельности, при изменении стратегии, при внедрении инноваций. 
Итак, система бизнес – процессов обеспечивает алгоритм деятельности:
Что делаем (действия: процессы, операции), на основании чего _ Чем обеспечиваются действия (инфраструктура, снабжение и др.) _ Как соединяются (управление) _ Что получаем в результате (продукт, показатели)
Смысл инжиниринга – содержание алгоритмов действий, а не форма их представления.
Система бизнес – процессов является базой для структурирования решений и действий, формирования ресурсной базы, подбора и расстановки кадров, системы обеспечения ресурсами.

Гибридная адаптивная  технология   проектирования   бизнес-процессов .
Аннотация. Объектом исследования является развитие автоматизированной системы трансформации компонент диаграмм языка структурного моделирования в диаграммы классов на основе гибридной адаптивной технологии проектирования бизнес-процессов, включающей IDEF0, UML, OWL, RDF, XML, XSLT. Показана возможность определения правил трансформации с использованием онтологического описания.