Двести лет назад Адам Смит сделал выдающееся открытие: индустриальное производство должно быть разбито на простейшие и самые базовые операции. Он показал, что разделение труда способствует росту производительности, так как сосредоточенные на одной задаче рабочие становятся более искусными мастерами и лучше выполняют свою работу. И на протяжении XIX и XX веков люди организовывали, развивали компании, управляли ими, руководствуясь принципом разделения труда Адама Смита.
Однако в современном мире достаточно внимательно посмотреть на любую компанию – от уличного ларька до транснационального гиганта типа Microsoft или Coca-Cola. Обнаружится, что деятельность компаний состоит из огромного количества повторяющихся бизнес-процессов, каждый из которых представляет собой последовательность действий и решений, направленных на достижение определенной цели. Прием заказа клиента, доставка товара клиенту, начисление зарплаты сотрудникам – всё это бизнес-процессы.
Вполне очевидно, что эффективность деятельности компании в значительной степени определяется эффективностью реализации бизнес-процессов в этой компании. В середине 80-х годов, когда возможности экстенсивного роста компаний в развитых странах были уже давно исчерпаны, специалисты по управленческим технологиям в поисках возможностей по радикальному повышению эффективности, прибыльности и стоимости бизнеса обратили свое внимание на проблему эффективности реализации бизнес-процессов. И обнаружили, что даже в передовых, с точки зрения управленческих технологий, компаниях существуют возможности повышения эффективности отдельных подразделений и компании в целом путём оптимизации бизнес-процессов на различных уровнях компании.
Оказалось, что даже в лучших компаниях многие стратегически важные бизнес-процессы реализованы настолько неэффективно, что затраты времени и ресурсов могут быть сокращены в десятки раз совершенно без ущерба для качества выполнения задачи, реализуемой данным бизнес-процессом. Исследования, проведенные в российских компаниях, дали аналогичные результаты.
Это открытие дало толчок развитию новой управленческой дисциплины, получившей название реинжиниринга бизнес-процессов. Именно реинжиниринг стал одним из важнейших рычагов успешной перестройки американских компаний, позволив им успешно вернуть мировое лидерство в эффективности и обеспечить невиданный рост американской экономики и фондового рынка.
По данным компании Emst & Young, 100 крупнейших банков Северной Америки затратили в 1999 году около 3,9 млрд. долларов только на реинжиниринг своих подразделений. За последние полтора года правительство США инициировало более 250 проектов по реинжинирингу, а сегодняшний рынок инструментальных средств поддержки реинжиниринга бизнес-процессов оценивается более чем в 100 млн. долларов и растет со скоростью около 60% в год.
Бизнес-процессы - это горизонтальные иерархии внутренних и зависимых между собой функциональных действий, конечной целью которых является выпуск продукции или отдельных ее компонентов .
Существуют следующие категории бизнес-процессов:
· Процессы, непосредственно обеспечивающие выпуск продукции;
· Процессы планирования и управления;
· Ресурсные процессы;
· Процессы преобразования.
Бизнес-процесс характеризуется:
· Существующей технологией реализации бизнес-процесса;
· Существующей структурой бизнес-системы;
· Средствами автоматизации, оборудованием, механизмами и т.п., обеспечивающими реализацию процесса.
Основными показателями оценки эффективности бизнес-процессов являются:
· Количество производимой продукции заданного качества, оплаченное за определенный интервал времени;
· Количество потребителей продукции;
· Количество типовых операций, которые необходимо выполнить при производстве продукции за определенный интервал времени;
· Стоимость издержек производства продукции;
· Длительность выполнения типовых операций;
· Капиталовложения в производство продукции.
При изменении условий работы организации принятая в ней система бизнес-процессов может стать неэффективной, что требует некоторого целенаправленного изменения этой системы, или оптимизации бизнес-процессов.
Оптимизация – это фундаментальное переосмысление бизнес-процессов компании для достижения коренных улучшений в основных актуальных показателях их деятельности: стоимость, качество, услуги и темпы.
Действия, сопровождающие оптимизацию и приводящие к повышению эффективности работы предприятия:
1. Несколько рабочих процедур объединяются в одну. Происходит горизонтальное сжатие процесса. Если не удается привести все шаги процесса к одной работе, то создается команда, отвечающая за данный процесс, что неизбежно приводит к некоторым задержкам и ошибкам, возникающим при передаче работы между членами команды.
2. Исполнители принимают самостоятельные решения. При этом происходит вертикальное сжатие, процессов. Наделение сотрудников большими полномочиями и увеличение роли каждого из них в работе предприятия приводит к значительному повышению их отдачи.
3. Шаги процесса выполняются в естественном, а не в линейном, порядке. Это позволяет распараллеливать процессы там, где это возможно.
4. Процессы имеют различные варианты исполнения. Процесс должен иметь различные версии исполнения в зависимости от конкретной ситуации, причем каждый вариант должен быть простым и понятным.
5. Работа выполняется в том месте, где это целесообразно. При этом распределяется работа между границами подразделений и устраняется излишняя интеграция.
6. Уменьшается количество проверок и управляющих воздействий. Они должны выполняться в отлаженном режиме, что приведет к сокращению времени и стоимости процессов.
7. Минимизируется количество согласований (за счет сокращения внешних точек контакта). При этом стираются грани между функциональными подразделениями.
8. «Уполномоченный» менеджер обеспечивает единую точку контакта. Этот механизм применяется, когда необходимо обеспечить участие заказчика в сложном процессе.
9. Преобладает смешанный централизованно/децентрализованный подход. При этом подразделения предприятия могут действовать полностью автономно при наличии единого корпоративного хранилища данных.
Структурный подход основан на использовании различных типов организационной структуры предприятия, как правило, иерархической. В этом случае организация и управление деятельностью осуществляется по структурным элементам (бюро, отделам, департаментам, цехам и т.п.), а их взаимодействие - через должностных лиц (начальников отделов, департаментов и цехов) и структурные подразделения более высокого уровня.
Недостатки:
· При разбиении технологий выполнения отдельной работы на отдельные фрагменты они могут быть отнесены к различным элементам организационной структуры;
· Затруднено цельное описание технологий выполнения работы, в основном существует только их фрагментарное (на уровне структурных элементов) описание;
· Отсутствие ответственного за конечный результат, заинтересованности в конечном результате, а также ориентации на конечного потребителя;
· Отсутствие промежуточных результатов деятельности, ответственных за эти результаты, внутренних потребителей этих результатов;
· Большие затраты на передачу результатов между подразделениями.
· Высокие накладные расходы, крайне неэффективный управленческий учет;
· Попытки внедрения корпоративных информационных систем в основном оканчиваются неудачей.
Результат функционального подхода – оптимальное проектирование организационной структуры – определение границ между подразделениями по принципу функциональных областей. Начальный набор типовых функций детализируется и привязывается к конкретному предприятию, к его службам и подразделениям.
Функциональный подход отвечает на вопрос «Что делать?».
Функционально-структурная модель основана на универсальном принципе разделения труда между службами, отделами, цехами, бригадами с закреплением за ними определенных функций.
Недостатки функционального подхода те же, что и структурного, но они менее явно выражены, и тем меньше, чем больше внимания уделялось минимизации пересечения границ структурных подразделений в процессе работы.
Процессный подход на является противопоставлением функциональному. Функции и процессы не могут существовать в отрыве друг от друга. Результат и функционального, и процессного подходов - одновременное проектирование организационной структуры и порядка взаимодействий в рамках этой структуры. Эти подходы должны применяться параллельно.
Основное отличие процессного подхода в том, что он ориентирован, в первую очередь, не на организационную структуру предприятия, не на функции подразделений, а на бизнес-процессы, конечными целями выполнения которых, является создание продуктов или услуг, представляющих ценность для внешних или внутренних потребителей. При этом система управления компанией ориентируется как на управление каждым бизнес-процессом в отдельности, так и всеми бизнес-процессами предприятия в целом. При этом система качества предприятия обеспечивает качество технологии выполнения бизнес-процессов.
Процессный подход отвечает на вопрос «Как делать?».
Процессный подход по своей сути подводит к переходу на ресурсосберегающую организационную структуру. Основными чертами такой организационной структуры являются:
· широкое делегирование полномочий и ответственности исполнителям;
· сокращение количества уровней принятия решения;
· сочетание принципа целевого управления с групповой организацией труда;
· повышенное внимание к вопросам обеспечения качества продукции или услуг, а также работы предприятия в целом;
· автоматизация технологий выполнения бизнес-процессов.
Проектный подход применяется для проектно-ориентированных компаний, например, научно-исследовательских, консалтинговых, строительных и т.д. Он может применяться и для любой компании при создании инновационных проектов в рамках этих проектов.
Основным принципом построения проектной структуры является концепция не функций или процессов, а проекта – создание нового, как правило, единичного не повторяющегося продукта, например, разработка нового изделия, создание и внедрение новой технологии, строительство объекта и т. д.
Деятельность предприятия в этом случае рассматривается как совокупность выполняемых проектов, каждый из которых имеет фиксированное начало и окончание. Под каждый проект выделяются трудовые, финансовые, промышленные и т. д. ресурсы, которыми распоряжается руководитель проекта. Управление проектом включает определение его целей, формирование структуры, планирование и организацию работ, координацию действий исполнителей.
После выполнения проекта структура проекта распадается, ее компоненты, включая сотрудников, переходят в новый проект.
По форме структура управления по проектам может соответствовать как бригадной, так и дивизионной структуре, в которой определенный дивизион (отделение) создается под конкретный проект и существует не постоянно, а на срок выполнения проекта.
Преимущества структуры управления по проектам:
· высокая гибкость;
· сокращение численности управленческого персонала по сравнению с иерархическими структурами.
Можно выделить четыре главных принципа.
Принцип первый. У оптимизации должна быть основа. Суть этого принципа заключается в том, что перед тем как проводить оптимизацию, надо четко выделить бизнес-процессы. Надо сначала «увидеть» ход протекания процессов, то есть зафиксировать их в виде моделей «как есть». Ведь если не удается описать процессы, происходящие в настоящее время (например, из-за их высокой изменчивости), то и оптимизировать будет нечего (в данной ситуации можно выстраивать процессы заново, оценивать их оптимальность и улучшать уже новые процессы).
Принцип второй. Оценивать оптимальность надо от частного к общему, выявляя отдельные недостатки, объединяя их в группы и оперативно устраняя.
Принцип третий. Решения по оптимизации - неоднозначны. Велика вероятность того, что устраняя не оптимальность по одному критерию, мы ухудшаем процесс по другому. Надо уметь выявлять такие последствия, оценивать преимущества и недостатки и делать обоснованный выбор.
Принцип четвертый. Следствием настоящей оптимизации процессов является усиление эксплуатации исполнителей, поэтому неизбежно сопротивление персонала.
Из приведённых выше принципов следуют условия и шаги проведения оптимизации:
1) Перед тем как начинать работу по оптимизации, необходимо описать существующие в компании бизнес-процессы «как есть» (создать их модели). Описания должны быть четкими, однозначными и затрагивать уровень, на котором видна конкретная работа сотрудников. Объем моделей может быть разным: как по отдельно выделенному, так и по группе взаимосвязанных бизнес-процессов. Безусловно, чем больше процессов описано в модели, тем лучше и шире можно оценить их оптимальность.
2) Оценивая оптимальность, в первую очередь надо анализировать каждую часть бизнес-процесса, выполняемую конкретным исполнителем (процедуру). Оценивая ее, надо проверять, к каким результатам приводит правильное выполнение, какие данные или материалы исполнитель получает в итоге, что он с ними делает, насколько оптимальны его действия, а также время работы и продолжительность выполнения процедуры.
3) Проанализировав каждую процедуру и определив ее явные недостатки, можно оценить оптимальность управления бизнес-процессом и оптимальность группы процессов. Результатами оценки оптимальности должны стать выявленные недостатки в процессе и/или группе процессов.
4) Затем надо разработать предложения по исправлению выявленных недостатков, перестроить модель процесса («как будет»), учитывая данные предложения, пересмотреть действия исполнителей и кандидатуры самих исполнителей (если это необходимо), а самое главное - улучшить средства труда. Улучшение средств труда заключается в усовершенствовании форм фиксации, хранения и первичной обработки данных, используемых при выполнении конкретной процедуры.
5) На завершающем шаге надо оценить возможные ухудшения от предлагаемых улучшений в других местах процесса, в том числе и возможное сопротивление сотрудников.
Моделирование бизнес-процесса - процесс отражения субъективного видения потока работ в виде формальной модели, состоящей из взаимосвязанных операций.
В настоящее время на рынке компьютерных технологий представлены несколько специальных программ, позволяющих обследовать предприятие и построить модель. Выбор методологии и инструментов, с помощью которых проводится моделирование бизнес-процессов, основополагающего значения не имеет. Существуют стандартизированные, опробованные временем методологии и инструментальные средства, с помощью которых можно обследовать предприятие и построить его модель. Ключевое их преимущество - простота и доступность к овладению.
Наиболее известной и распространенной методикой является методология структурного анализа SADT (Structured Analysis and Design Technique). На основе этой методологии был принят стандарт моделирования бизнес-процессов IDEF0 .
Главное достоинство идеи анализа бизнес-процессов предприятия посредством создания его модели - ее универсальность. Во-первых, моделирование бизнес-процессов это ответ практически на все вопросы, касающиеся совершенствования деятельности предприятия и повышения его конкурентоспособности. Во-вторых, руководитель или руководство предприятия, внедрившие у себя конкретную методологию, будет иметь информацию, которая позволит самостоятельно совершенствовать свое предприятие и прогнозировать его будущее.
Моделирование бизнес-процессов позволяет проанализировать не только как работает предприятие в целом, как оно взаимодействует с внешними организациями, заказчиками и поставщиками, но и как организована деятельность на каждом отдельно взятом рабочем месте.
Существует несколько подходов к определению понятия «моделирование бизнес-процессов»:
1) моделирование бизнес-процессов - это описание бизнес-процессов предприятия, позволяющее руководителю знать, как работают рядовые сотрудники, а рядовым сотрудникам - как работают их коллеги и на какой конечный результат направлена вся их деятельность ;
2) моделирование бизнес-процессов - это эффективное средство поиска возможностей улучшения деятельности предприятия;
3) моделирование бизнес-процессов - это средство позволяющее предвидеть и минимизировать риски, возникающие на различных этапах реорганизации деятельности предприятия;
4) моделирование бизнес-процессов - это метод, позволяющий дать оценку текущей деятельности предприятия по отношению к требованиям, предъявляемым к его функционированию, управлению, эффективности, конечным результатам деятельности и степени удовлетворенности клиента ;
5) моделирование бизнес-процессов - это метод, позволяющий дать стоимостную оценку каждому процессу, взятому в отдельности, и всем бизнес-процессам на предприятии, взятым в совокупности;
6) моделирование бизнес-процессов - это всегда верный способ выявления текущих проблем на предприятии и предвидения будущих.
Современные предприятия вынуждены постоянно заниматься улучшением своей деятельности. Это требует разработки новых технологий и приемов ведения бизнеса, повышения качества конечных результатов деятельности и внедрения новых, более эффективных методов управления и организации деятельности предприятий.
Бизнес-процесс – это логичный, последовательный, взаимосвязанный набор мероприятий, который потребляет ресурсы производителя, создает ценность и выдает результат потребителю. Среди основных причин, побуждающих организацию оптимизировать бизнес-процессы, можно выделить необходимость снижения затрат или длительности производственного цикла, требования, предъявляемые потребителями и государством, внедрение программ управления качеством, слияние компаний, внутриорганизационные противоречия и др. .
Моделирование бизнес-процессов – это эффективное средство поиска путей оптимизации деятельности компании, средство прогнозирования и минимизации рисков, возникающих на различных этапах реорганизации предприятия. Этот метод позволяет дать стоимостную оценку каждому отдельному процессу и всем бизнес-процессам организации в совокупности.
Решения по моделированию бизнес-процессов обычно принимается по причинам, представленным на рисунке 1.
Рисунок 1 - Причины, по которым принимается решение по моделированию бизнес-процессов
Моделирование бизнес-процессов затрагивает многие аспекты деятельности компании:
· изменение организационной структуры;
· оптимизацию функций подразделений и сотрудников;
· перераспределение прав и обязанностей руководителей;
· изменение внутренних нормативных документов и технологии проведения операций;
· новые требования к автоматизации выполняемых процессов и т. д.
Целью моделирования является систематизация знаний о компании и её бизнес-процессах в наглядной графической форме более удобной для аналитической обработки полученной информации. Модель должна отражать структуру бизнес-процессов организации, детали их выполнения и последовательность документооборота.
Моделирование бизнес-процессов организации включает два этапа структурное и детальное.
Структурное моделирование бизнес-процессов организации может выполняться в нотации IDEF0 с использованием инструментария BPwin или на языке UML с использованием инструментария Rational Rose. Детальное моделирование выполняется на языке UML.
На этапе структурного моделирования в модели должны быть отражены:
· существующая организационная структура;
· документы и иные сущности, используемые при исполнении моделируемых бизнес-процессов и необходимые для моделирования документооборота, с описаниями их основного смысла;
· структуру бизнес-процессов, отражающую их иерархию от более общих групп к частным бизнес-процессам;
· диаграммы взаимодействия для конечных бизнес-процессов, отражающие последовательность создания и перемещения документов (данных, материалов, ресурсов и т.п.) между действующими лицами.
Подготовленная модель должна быть согласованна архитекторами и ведущими программистами, подтверждая, что структура бизнес-процессов понятна.
Детальное моделирование бизнес-процессов выполняется в той же модели и должно отражать требуемую детализацию и должна обеспечить однозначное представление о деятельности организации.
Детальная модель бизнес-процесса должна включать:
· набор прецедентов отражающих возможные варианты выполнения бизнес-процессов «как есть»;
· диаграммы действий, детально описывающие последовательность выполнения бизнес-процессов;
· диаграммы взаимодействия, отражающие схемы документооборота.
Модели должны быть согласованы с ведущими специалистами организации, обладающими необходимыми знаниями.
В случае если после построения моделей согласование не было достигнуто – в модель должны быть внесены необходимые уточнения и коррективы. Процесс итерации (согласование, внесение корректив и уточнений) должен повторяться до момента полного подтверждения, что модель понятна и однозначно представляет детали бизнес-процессов.
Под методологией создания модели бизнес-процесса понимается совокупность способов, при помощи которых объекты реального мира и связи между ними представляются в виде модели. Любая методология включает три основные составляющие:
· теоретическая база;
· описание шагов, необходимых для получения заданного результата;
Моделирование бизнес-процессов можно выполнять с применением различных подходов, методологий, нотаций и инструментальных средств - в зависимости от требований к модели в каждом конкретном случае. Требования определяются процессом создания системы автоматизации в целом, в рамках которого проводится моделирование предметной области. Этот процесс определяет, каким образом будет строиться, уточняться и использоваться модель.
Как правило, система создается коллективом людей. Эти люди имеют различные специальности, опыт, привычки, образование, предпочтения и личные качества. Модель бизнес-процессов строится для того, чтобы эти люди могли эффективно обмениваться знаниями и совместно принимать решения по ходу создания системы. Модель является языком общения между сторонами, участвующими в создании системы автоматизации, - заказчиками, экспертами, архитекторами и т. д. Она должна быть организована таким образом, чтобы каждая сторона, воспринимающая моделируемую систему с собственной точки зрения, могла эффективно вносить свой вклад в общее понимание предметной области.
Процесс создания автоматизированной системы часто оказывается итеративным, поэтому модель должна допускать последовательные уточнения. В идеале модель должна строиться таким образом, чтобы при ее детализации не изменялись ранее построенные более общие элементы модели, а только добавлялись бы новые .
Модель должна быть устойчива к изменениям предметной области. Это значит, что она должна быть организована таким образом, чтобы при изменениях предметной области изменялся только некоторый минимально необходимый набор элементов модели. Более того, модель сама должна быть инструментом реорганизации бизнес-процессов в рамках создания системы автоматизации.
Необходимо учитывать важные характеристики моделирования бизнес-процессов.В частности, к преимуществаммоделирования бизнес-процессов относят:повышение качества и скорости производства продукции с одновременным снижением издержек; рост профессионализма сотрудников; повышение конкурентоспособности компании. Недостатки:усиление эксплуатации сотрудников и связанные с этим проблемы социально-психологического характера; необходимость проведения целенаправленной работы по изменению корпоративной культуры.
Основу многих современных методологий моделирования бизнес-процессов составила методология SADT (Structured Analysis and Design Technique) – метод структурного анализа и проектирования) и алгоритмические языки, применяемые для разработки программного обеспечения .
В сжатом виде история развития методологий моделирования бизнес-процессов представлена на рисунке 2. Для наглядности параллельно приведена история развития подходов к управлению качеством .
Рисунок 2 - История развития методологий моделирования бизнес-процессов
В настоящее время для описания, моделирования и анализа бизнес-процессов используются несколько типов методологий. К числу наиболее распространенных типов относятся следующие методологии:
Моделирования бизнес-процессов (Business Process Modeling);
Описания потоков работ (Work Flow Modeling);
Описания потоков данных (Data Flow Modeling).
Наиболее широко используемая методология описания бизнес-процессов – стандарт США IDEF0. С момента разработки стандарт не претерпел существенных изменений. В настоящее время развитие методологии IDEF0 сопряжено с совершенствованием поддерживающих ее инструментов – программных продуктов для моделирования бизнес-процессов (например, BPWin 4.0, ProCap, IDEF0/EM Tool и др.). Методология IDEF0 предоставляет аналитику широкие возможности для описания бизнеса организации на верхнем уровне с акцентом на управление процессами. Нотация позволяет отражать в модели процесса обратные связи различного типа – по информации, управлению, движению материальных ресурсов .
С помощью методологии семейства IDEF можно эффективно отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными. В настоящий момент к семейству IDEF можно отнести следующие стандарты :
IDEF0 - методология функционального моделирования. С помощью наглядного графического языка IDEF0, изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций. Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы;
IDEF1 – методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи;
IDEF1X (IDEF1 Extended) – методология построения реляционных структур. IDEF1X относится к типу методологий “Сущность-взаимосвязь” (ER – Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных;
IDEF2 – методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе;
IDEF3 – методология документирования процессов, происходящих в системе, которая используется, например, при исследовании технологических процессов на предприятиях. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 – каждая функция может быть представлена в виде отдельного процесса средствами IDEF3;
IDEF4 – методология построения объектно-ориентированных систем. Средства IDEF4 позволяют наглядно отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;
IDEF5 – методология исследования сложных систем .
Система ARIS представляет собой комплекс средств анализа и моделирования деятельности предприятия. Ее методическую основу составляет совокупность различных методов моделирования, отражающих разные взгляды на исследуемую систему. Одна и та же модель может разрабатываться с использованием нескольких методов, что позволяет использовать ARIS специалистам с различными теоретическими знаниями и настраивать его на работу с системами, имеющими свою специфику .
ARIS поддерживает четыре типа моделей, отражающих различные аспекты исследуемой системы:
· организационные модели, представляющие структуру системы - иерархию организационных подразделений, должностей и конкретных лиц, связи между ними, а также территориальную привязку структурных подразделений;
· функциональные модели, содержащие иерархию целей, стоящих перед аппаратом управления, с совокупностью деревьев функций, необходимых для достижения поставленных целей;
· информационные модели, отражающие структуру информации, необходимой для реализации всей совокупности функций системы;
· модели управления, представляющие комплексный взгляд на реализацию бизнес-процессов в рамках системы.
Для построения перечисленных типов моделей используются как собственные методы моделирования ARIS, так и различные известные методы и языки моделирования - ERM, UML, OMT и др.
В процессе моделирования каждый аспект деятельности предприятия сначала рассматривается отдельно, а после детальной проработки всех аспектов строится интегрированная модель, отражающая все связи между различными аспектами.
Модели в ARIS представляют собой диаграммы, элементами которых являются разнообразные объекты - "функция", "событие", "структурное подразделение", "документ" и т.п. Между объектами устанавливаются разнообразные связи. Каждому объекту соответствует определенный набор атрибутов, которые позволяют ввести дополнительную информацию о конкретном объекте. Основная бизнес-модель ARIS - eEPC (extended Event Driven Process Chain - расширенная модель цепочки процессов, управляемых событиями). По существу, она расширяет возможности IDEF0, IDEF3 и DFD, обладая всеми их достоинствами и недостатками. Применение большого числа различных объектов, связанных различными типами связей, может значительно увеличить размер модели и сделать ее плохо читаемой .
В заключение краткого описания существующих методологий следует отметить, что бизнес-процессы предприятия могут быть представлены при помощи стандартных блок-схем, которые, по сути, основаны на идеологии нотации IDEF3, но при этом содержат некоторые дополнительные специальные графические объекты. Использование этих объектов позволяет сделать блок-схемы процессов более наглядными и понятными для исполнителей.
Сводная информация об основных существующих сегодня методологиях представлена на рисунке 3 .
Рисунок 3 - Методологии моделирования бизнес-процессов
Таким образом, компания, решившаяся на оптимизацию бизнес-процессов, может выбрать методологию из нескольких стандартных, использовать простейшие блок-схемы или, наконец, разработать собственную форму описания. Выбор методологий должен базироваться на понимании их возможностей и недостатков, а также целей использования создаваемых моделей бизнес-процессов.
Моделирование и оптимизация бизнес-процессов позволяет проанализировать не только, как работает предприятие в целом, как оно взаимодействует с внешними организациями, заказчиками и поставщиками, но и как организована деятельность на каждом отдельно взятом рабочем месте.
Предприятие, которое не осуществляет инвестиции в изменения, ставит на карту свою способность к выживанию на рынке, но само стремление к переменам не является гарантией выживания в конкурентной борьбе. Необходимо умелое управление этими переменами.
Результатом моделирования и оптимизации бизнес-процессов является экспертное заключение, в котором отдельными пунктами выносятся рекомендации по устранению «узких мест» в управлении деятельностью.
Под методологией (нотацией) создания модели (описания) бизнес-процесса понимается совокупность способов, при помощи которых объекты реального мира и связи между ними представляются в виде модели.
Основу многих современных методологий моделирования бизнес-процессов составила методология SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования) и алгоритмические языки, применяемые для разработки программного обеспечения. С помощью методологии семейства IDEF можно эффективно отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. Система ARIS представляет собой комплекс средств анализа и моделирования деятельности предприятия. Ее методическую основу составляет совокупность различных методов моделирования, отражающих разные взгляды на исследуемую систему.
1. Елиферов, В.Г. Бизнес-процессы / В.Г. Елиферов, В.В. Репин. – М.: Инфра-М, 2005.- 319 с.
2. Уткин, Э.А. Бизнес-реинжиниринг. Обновление бизнеса / Э.А. Уткин. – М.: ЭКМОС, 1998.
3. Шеер, А.В. Моделирование бизнес-процессов / А.В. Шеер. – М.: Весть-МетаТехнология, 2000.
4. Маклаков, С.В. BPwin и ERwin. CASE‑средства разработки информационных систем / С. В. Маклаков. – М.: ДИАЛОГ-МИФИ, 1999.
5. Григорьев, Д. Моделирование бизнес-процессов предприятия. /Д. Григорьев // http://www.valex.net/articles/process.html.
6. Волков, О. Стандарты и методологии моделирования бизнес-процессов. / О. Волков // Корпоративное издание Связьинвест. - JN 7. - 2005.
7. Войнов, И.В. Моделирование экономических систем и процессов. Опыт построения ARIS-моделей: Монография / И.В. Войнов, С.Г. Пудовкина, А.И. Телегин. - Челябинск: Изд. ЮУрГУ, 2002. – 392 с.
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Министерство образования и науки РФ
Федеральное государственное бюджетное образовательное учреждение
высшего профессионального образования
Нижегородский государственный технический университет имени Р.Е. Алексеева
Институт Экономики и управления
Кафедра "Экономика, управление и финансы"
Курсовая работа
по дисциплине: "Моделирование бизнес-процессов и экономических систем"
на тему: «Моделирование бизнес-процессов. Основные этапы проекта по внедрению процессного подхода в компании»
Выполнил:
студент гр. 10ИНМк
Резвова А.В.
Проверил:
Ковылкин Д.Ю.
Нижний Новгород 2014 г.
Введение
1.2 Основные терминологии
2. Практическая часть
2.1 Исходные данные
2.2 Проектная часть
Заключение
Список использованных источников и литературы
Введение проектирование управление процессный
Реорганизация деятельности компаний, особенно если такая реорганизация связана с внедрением корпоративных информационных систем, связана с серьезным риском.
К сожалению, можно привести множество примеров, когда проекты по внедрению готовых или разработанных под заказ информационных систем оканчивались неудачей.
Между тем существующие и опробованные в течение многих лет методики и инструментальные средства позволяют минимизировать риски и решать ключевые вопросы, возникающие на различных этапах реорганизации бизнес-процессов компаний, в том числе реорганизации, сопровождающейся внедрением информационных систем.
1. Основные этапы проекта по внедрению процессного подхода в компании
1.1 Возможности процессной системы управления
В настоящее время многие российские предприятия занимаются внедрением процессного подхода к управлению, проводят подготовку и сертификацию по стандартам ISO серии 9000:2000, автоматизируют деятельность при помощи корпоративных информационных систем (SAP R/3, BAAN и др.), внедряют системы стратегического управления. На практике часто складывается ситуация, когда в организации одновременно ведутся несколько проектов, которые частично дублируют задачи друг друга, непроизводительно расходуя ресурсы предприятия. Одновременно на предприятии могут проводиться следующие работы:
· отдел развития занимается описанием и реинжинирингом бизнес-процессов с использованием методик ARIS или IDEF для целей улучшения управления;
· служба по качеству описывает и регламентирует бизнес-процессы в своем формате для целей внедрения системы качества (СК) или системы менеджмента качества (СМК);
· служба информатизации (IT-подразделение) собирает информацию по бизнес-процессам для подготовки и внедрения ERP-системы.
На мой взгляд, такая ситуация во многом обусловлена невниманием руководства к проектам, которые выполняются на предприятии. В результате на предприятии создается множество отличающихся друг от друга, не связанных между собой, плохо проработанных документов, которые, по сути, предназначены для решения одной задачи - регламентации бизнес-процессов предприятия для целей эффективного управления. Для предприятия и его собственников такое положения дел означает неэффективное, даже бесхозяйственное расходование ресурсов: финансовых, материальных, человеческих, ресурсов времени. Вместо достижения конкурентных преимуществ и улучшения управляемости, предприятие растрачивает впустую капитал и время, создает хаос в управлении и постепенно уступает рынок более эффективным конкурентам.
В связи со сказанным выше, я предлагаю создавать на предприятии единую систему управления бизнес-процессами (СУБП), которая позволяет комплексно решать основные задачи управления и развития предприятия.
Внедрение процессного подхода к управлению дает предприятию следующие возможности.
Возможность 1. Система процессного управления позволяет оптимизировать систему общего корпоративного управления, сделать ее прозрачной для руководства и способной гибко реагировать на изменения внешней среды. Система процессного управления регламентирует:
· порядок планирования целей и деятельности;
· взаимодействие между процессами и подразделениями предприятия;
· ответственность и полномочия должностных лиц, в т.ч. владельцев процессов;
· порядок работы и действий в нештатных ситуациях;
· порядок и формы отчетности перед высшим руководством;
· систему показателей, характеризующих результативность и эффективность деятельности предприятия в целом и его процессов;
· порядок рассмотрения результатов деятельности и принятие управленческих решений по устранению отклонений и достижению плановых показателей.
Внедрение на предприятии СУБП в первую очередь подразумевает работу по описанию и регламентации бизнес-процессов, в рамках которой:
· проводится распределение ответственности за результаты работ, входящих в состав процессов;
· определяется система взаимодействия процессов между собой и с внешними поставщиками и потребителями;
· определяется перечень документации, необходимой для функционирования процессов (инструкции, порядки, положения, методики, должностные инструкции и т.д.);
· составляется график разработки и внедрения этой документации;
· устанавливаются показатели деятельности процессов, способы и формы сбора информации и порядок отчетности перед руководителями;
· определяются границы показателей, характеризующие нормальное течение процессов;
· устанавливаются критерии, по которым начинается работы по устранению причин отклонения.
Возможность 2. Система процессного управления позволяет получить и использовать систему показателей и критериев оценки эффективности управления на каждом этапе производственной/управленческой цепочки. Система показателей, построенная в рамках процессного управления, структурируется по четырем направлениям:
· показатели результата деятельности отдельных процессов и предприятия в целом (достижение запланированных результатов - по объему, качеству, номенклатуре и срокам);
· показатели эффективности деятельности отдельных процессов и предприятия в целом (отношение полученных результатов к затратам времени, финансовых и других ресурсов);
· показатели продуктов, производимых процессами предприятия;
· показатели удовлетворенности клиентов результатами работы.
Система процессного управления предусматривает двухступенчатую систему показателей: а) показатели, по которым владелец процесса оценивает результативность и эффективность своего процесса и работ, входящих в его состав; б) показатели, по которым владелец процесса отчитывается перед высшим руководством о результатах деятельности процесса. В число процессов, которые существуют в организации, входит процесс управления организацией. Владельцем этого процесса является Генеральный директор. Управление деятельностью предприятия производится на основе отчетных показателей, которые владельцы процессов передают высшему руководству.
Возможность 3. СУБП обеспечивает уверенность у соучредителей предприятия в том, что существующая система управления нацелена на постоянное повышение эффективности и максимальный учет интересов заинтересованных сторон поскольку:
· система основана на измерении показателей деятельности предприятия, планировании и достижении непрерывного улучшения результатов деятельности;
· система направлена на удовлетворение потребностей 5 групп лиц, заинтересованных в деятельности организации:
A. 1) соучредители (инвесторы);
2)потребители на рынке;
3) персонал организации;
4) поставщики.
5) общество.
Возможность 4. Внедрение процессного подхода и построение системы менеджмента качества гарантирует четко определенный порядок и ответственность за разработку, согласование, утверждение и ведение документации, соответствие ее действующей нормативной базе РФ.
Возможность 5. Основой процессного управления является принятия решений основанное на фактах, поэтому большое значение для создания процессного управления имеет наличие в организации информационной системы. Внедряемая на предприятии информационная система позволяет получать владельцам процессов объективную информацию для ведения управления в том случае, если она строится в рамках единой системы управления предприятием на основе процессного подхода. В том случае, если система автоматизации внедряется без учета потребностей реального управления организацией, то очень велика вероятность неудачного завершения такого проекта.
Внедрение процессной системы управления на предприятии рассматривается как проект. Основным заказчиком результатов этого проекта является высшее руководство предприятия и владельцы процессов.
1.2 Основные терминологии
Бизнес-процесс - устойчивая, целенаправленная совокупность взаимосвязанных видов деятельности (последовательность работ), которая по определенной технологии преобразует входы в выходы, представляющие ценность для потребителя.
Владелец бизнес-процесса - должностное лицо, которое имеет в своем распоряжении персонал, инфраструктуру, программное и аппаратное обеспечение, информацию о бизнес-процессе, управляет ходом бизнес-процесса и несет ответственность за результаты и эффективность бизнес-процесса.
Вход бизнес-процесса - ресурс, необходимый для выполнения бизнес-процесса и подвергаемый преобразованию в выход бизнес-процесса.
Выход бизнес-процесса - результат (продукт, услуга) выполнения бизнес-процесса.
Документооборот - система документального обеспечения деятельности предприятия.
Заказчик - должностное лицо, имеющее ресурсы и полномочия для принятия решения о проведении работ по описанию, регламентации или аудиту (проверке) бизнес-процесса.
Показатели бизнес-процесса - количественные и/или качественные параметры, характеризующие бизнес-процесс и его результат.
Показатели эффективности бизнес-процесса (ПЭ) - параметры бизнес-процесса, характеризующие взаимоотношение между достигнутым результатом и использованными ресурсами.
Показатели продукта (услуги)(ПП) - параметры продукта бизнес-процесса.
Показатели (данные) удовлетворенности клиента (потребителя) (ДУК) - параметры удовлетворенности клиента.
Поставщик - субъект, предоставляющий ресурсы.
Потребитель (клиент) - субъект, получающий результат бизнес-процесса. Потребитель может быть:
а) внутренний - то есть находящийся в организации и, в ходе своей деятельности, использующий результаты (выходы) предыдущего бизнес-процесса;
б) внешний - то есть находящийся за пределами организации и использующий или потребляющий результат деятельности (выход) организации.
Операция (работа) - часть бизнес-процесса.
Регламент бизнес-процесса - документ, описывающий последовательность операций, ответственность, порядок взаимодействия исполнителей и порядок принятия решений по улучшениям.
Ресурсы - информация (документы, файлы), финансы, материалы, персонал, оборудование, инфраструктура, среда, программное обеспечение, необходимые для выполнения бизнес-процесса.
Модель - графическое, табличное, текстовое, символьное описание бизнес-процесса либо их взаимосвязанная совокупность.
Функция - направление деятельности элемента организационной структуры, представляющие собой совокупность однородных операций, выполняемых на постоянной основе.
Система управления любого предприятия включает в себя несколько подсистем, связанных с управлением предприятием, например: система стратегического планирования, система маркетинга и сбыта, система бухгалтерского учета и т.п. На практике очень часто складывается ситуация, когда многие из указанных выше подсистем проработаны на предприятии достаточно хорошо: создана документация, обучены специалисты, установлено программное обеспечение и т.д. Как правило, хуже всего обстоит дело с консолидацией всех этих подсистем в общую систему управления. За эту консолидацию несет ответственность руководство верхнего уровня предприятия, но именно для него менее всего проработана регламентирующая документация. Деятельность управленцев верхнего уровня не формализована, нигде не прописаны стандартные средства управления предприятием, которые должны постоянно использовать руководители верхнего уровня.
Система управления бизнес-процессами (СУБП) предоставляет руководителям верхнего уровня средства управления, позволяющие увязать воедино существующие подсистемы, устранить препятствия, существующие между подразделениями на пути бизнес-процессов.
1.3 Процессный подход: концепция внедрения в организации
Для определения зрелой с процессной точки зрения организации можно использовать следующие критерии:
* Наличие и поддержание в актуальном состоянии архитектуры (системы) бизнес-процессов компании;
* Действующая система стандартизации (регламентации) деятельности (в первую очередь процессов);
* Наличие и активное использование для мониторинга, анализа, улучшения и стимулирования системы показателей (метрик) по бизнес-процессам;
* Наличие компетентных специалистов в области моделирования, анализа и регламентации бизнес-процессов в каждом функциональном подразделении;
* Наличие центра компетенции (департамента отдела) по организационному развитию с представителями в каждом департаменте (функциональное подчинение);
* Автоматизация наиболее важных сквозных процессов.
Процесс - устойчивая целенаправленная совокупность взаимосвязанных видов деятельности, которая по определенной технологии преобразует входы в выходы, представляющие ценность для потребителя (клиента).
Под ресурсом понимается материальный или информационный объект, необходимый для выполнения процесса.
С точки зрения состояния ресурсы могут: A. Храниться; B. Перемещаться; C. Находиться в состоянии обработки.
Преобразуемый ресурс - тот, который подвергаетс- преобразованию в ходе выполнения процесса. Преобразованный ресурс - тот, к которому добавлен- определенная ценность при выполнении процесса.
Обеспечивающий ресурс необходим для выполнения процесса, но не преобразуется в ходе процесса.
Ресурс по управлению - необходимый для управлен-я процессом.
Вход процесса - преобразуемый ресурс или-ресурс по управлению, необходимый для выполнения процесса, поставляемый другими процессами.
Выход процесса - преобразованный при выпо-нении процесса ресурс.
Обеспечивающие ресурсы могут:
* Периодически по мере необходимости поставляться в процесс другими процессами;
* Выделяться процессу на постоянной основе.
В реальной жизни обеспечивающие ресурсы меняются:
A. Сотрудники приобретают опыт, стареют и так далее;
B. Оборудование изнашивается;
C. ПО морально устаревает.
Владелец процесса - должностное лицо, которо- имеет в своем распоряжении выделенные ресурсы, управляет ходом процесса и несет ответственность за результаты и эффективность процесса.
В целом владелец процесса - это руководитель, способ-ый как минимум:
1. Проводить мониторинг хода процесса;
2. Анализировать факторы, влияющие на процесс и приводящие к вариациям;
3. Разрабатывать предложения по улучшению процесса и организовывать их обсуждения и согласования;
4. Координировать или управлять внутренние совершенствования процесса.
2. Практическая часть
2.1 Исходные данные
В данном разделе осуществляется моделирование описанного ранее бизнес-процесса с использованием нотации моделирования IDEF0 семейства стандартов IDEF.
Создание контекстной диаграммы
Рассматриваются некие продажи через интернет магазин.
Основные процедуры в продаже через интернет магазин таковы:
· Обработка заявки клиента
· Сборка товара на складе
· Подготовка документации
· Доставка
Рис.1 Контекстная диаграмма - 1-й уровень декомпозиции
2.2 Проектная часть
Создание диаграммы декомпозиции
В диалоге «Activity Box Count» устанавливаем число работ на диаграмме нижнего уровня - 4 - и нажимаем ОК.
Рис.2 Диалог «Activity Box Count»
Автоматически будет создана диаграмма декомпозиции. Правой кнопкой мыши щелкаем по работе, выбираем Name и вносим имя работы. Повторяем операцию для всех трех работ. Затем вносим определение, статус и источник для каждой работы.
Рис.3 . Подпроцессы, входящие в бизнес-процесс «Продажа через интернет магазин» - 2-й уровень декомпозиции
2.3 Создание диаграммы декомпозиции A1
Декомпозируем работу «Поверка и внесение заказа».
Рис.4 Результаты декомпозиции подпроцесса «Обработка заявки клиента» 3-й уровень декомпозиции
Из данной декомпозиции виден процесс реализации о заявки клиента с направлением стрелки в проверки и внесение заказа, а так же во внесение заказа. Так же к проверке и внесение заказа направлены стрелки информация и о клиентах и система складского учета, а к внесению заказа - та жа система складского учета, информация о клиентах и наличие товара на складе. На выходе получаем из внесение заказа в подтверждение заказа по телефону.
2.4 Создание диаграммы декомпозиции A2
Декомпозируем работу «товар»
Рис 5. Результаты декомпозиции подпроцесса «Сборка товара на складе» 3-й уровень декомпозиции.
На входе, как и на предыдущей диаграмме имеется заявка клиента, пройдя через все блоки, на выходе получаем сформированные заявки клиента. Так же на диаграмме присутствую стрелки система складского учета, которые направлены на все блоки подсистемы.
2.5 Создание диаграммы декомпозиции A3
Декомпозируем работу «Подготовка накладной»
Рис. 6 Результаты декомпозиции подпроцесса «Подготовка документации» 3-й уровень декомпозиции.
Данная диаграмма почти завершающая. На ней видна вся информация о заказе (вход подсистемы), где в результате на выходе получаем чеки и маршрутный лист.
2.6 Создание диаграммы декомпозиции А4
Декомпозируем работу «Наличие накладной»
Рис.7. Результаты декомпозиции подпроцесса «Доставка» 3-й уровень декомпозиции.
Завершающий процесс. На входе сразу 3 стрелки: сформированные заявки клиентов, чеки, маршрутый лист. Пройдя через все блоки получаем на выходе товар и чек доставленные клиенту.
2.3 Выводы и комментарии по результатам проектирования
Из проведенной работы можно сделать вывод о успешном моделировании бизнес-процесса «Продажи через интернет магазин».
Была произведена декомпозиция бизнес-процесса «Продажи через интернет магазин» которая включила в себя 4 уровня декомпозиции: «Обработка заявки на складе», «Сборка товара на сладе», Подготовка документации», «Доставка». На 3 уровне декомпозиции включает в себя диаграммы декомпозиции всех подпроцессов составляющих бизнес-процесс контекстной диаграммы.
Я добились полного результата описания процессов, которые вполне реально можно применить на практике в каком либо предприятии.
Заключение
Целью курсовой работы являлось закрепление теоретических знаний и приобретение практических навыков самостоятельной работы при изучении курса «Моделирование бизнес-процессов и экономических систем». В результате выполнения курсовой работы, поставленные цели и задачи выполнены.
Любой производственный проект начинается с планирования. Планирование - это процесс разработки и последующего контроля за ходом реализации плана и его корректировки в соответствии с изменяющимися условиями, т.е. планирование - это процесс обработки информации по обоснованию предстоящих действий, определение экономически эффективных способов достижения цели. Для достижения наибольшего экономического эффекта предприятие должно использовать такие методы производства, которые являются эффективными, как с технологической стороны, так и с экономической точки зрения. Важными факторами также будет эффективное распределение ресурсов, система цен, эффективность и другие.
В результате анализа, были сформированы достаточно цельные и систематизированные знания в области исследования, которые в дальнейшем будут реализованы в построении диаграмм бизнес процесса.
Список используемой литературы
1. Моделирование бизнес-процессов и экономических систем: методические указания для выполнения курсовой работы студентам, обучающимся по профилю «Информационный менеджмент» направления 080200 «Менеджмент»/НГТУ; сост.: Д.Ю. Ковылкин. Н.Новгород, 2014. - 30 c.
2. Лекции по дисциплине «Инструментальные средства моделирования сложных систем», Д.Ю.Ковылкин. 2014.
Размещено на Allbest.ru
Подобные документы
Определение процессного подхода к управлению организацией. Моделирование бизнес-процессов; объекты и связи в IDEF0, преимущества и недостатки их использования. Процессно-организационная бизнес-модель компании ОАО "Урал"; паспорт процесса "Продажа".
курсовая работа , добавлен 03.05.2014
Роль процессного подхода при создании системы менеджмента качества. Виды и схемы процессов организации и методы управления ими. Краткая характеристика предприятия. Внедрение информационной системы как способ совершенствования бизнес-процессов предприятия.
дипломная работа , добавлен 21.03.2013
Экономическая сущность понятий "производственный процесс" и "бизнес-процесс". Организация производства на основе процессного подхода и ее недостатки. Анализ необходимости и основные этапы внедрения процессного подхода к управлению на ОАО "Ашасвет".
курсовая работа , добавлен 25.05.2009
Эффективное внедрение процессного подхода. Основные виды бизнес-процессов. Вопросы управления бизнес-процессами. Проект реинжиниринга бизнес процессов организации. Общая характеристика организации ООО "Мир стекла". Разработка бизнес-процесса организации.
курсовая работа , добавлен 17.11.2014
Целесообразность внедрения процессного управления на ООО "Мир Алюминия". Разработка рекомендаций и механизма оптимизации основных бизнес-процессов как пути совершенствования системы управления на исследуемом предприятии. Моделирование бизнес-процессов.
дипломная работа , добавлен 08.01.2012
Основные направления деятельности компании ООО "Кварта": стратегический анализ, описание бизнес-процессов. Анализ факторов, воздействующих на достижение стратегических целей. Реорганизация структуры как важный шаг к совершенствованию деятельности компании
дипломная работа , добавлен 28.04.2011
Системы реинжиниринга и оптимизации бизнес-процессов. Суть процессного подхода к управлению организацией. Проблема конкурентоспособности персонала в рамках эффективной системы обучения персонала. Финансовый анализ и планирование хозяйствующего субъекта.
реферат , добавлен 16.07.2016
Методы и инструментальные средства исследования бизнес-процессов. Моделирование организационной структуры склада и бизнес-процессов, описание стратегической карты. Показатели оценивания достижения целей. План действий по оптимизации деятельности склада.
контрольная работа , добавлен 22.02.2017
Характеристика процессного подхода к управлению. Классификация бизнес-процессов в зависимости от их места в организационной структуре компании, от степени их сложности и предназначения. Определение влияния стратегии организации на бизнес-процессы.
курсовая работа , добавлен 25.01.2016
Анализ финансово-хозяйственной деятельности ООО "ВТК". Применение процессного подхода в деятельности организации. Разработка мер по совершенствованию внешнеэкономической деятельности, целевая схема бизнес-процессов. Оценка экономической эффективности.
Предисловие
Управление бизнес-процессами – важнейший элемент системы управления современной компании. Методики процессного управления активно развиваются. Появляются новые и совершенствуются существующие инструменты для описания и регламентации бизнес-процессов. Активно используются подходы и инструменты для управления процессами на основе показателей (метрик). Но собственникам и руководителям компаний подчас не хватает системного понимания возможностей процессного подхода и методов его внедрения. Для совершенствования управления нужно системно
представлять себе существующие возможности. Эта книга – о концепции внедрения и возможностях современных методик и инструментов. Моя цель – передать системную картину, необходимые методики и практический опыт внедрения. Надеюсь, что осмысление опыта десятков консалтинговых проектов, проведения обучения сотрудников компаний позволит это сделать.
Глава 1 посвящена общей концепции внедрения процессного подхода, разъяснению основных терминов и определений. В ней приводится обоснование эффективности внедрения процессного подхода, рассматриваются типовой план проекта внедрения и необходимые для этого методики и инструменты.
В главе 2 обсуждается один из важнейших методов – определение, анализ и реорганизация сквозных (межфункциональных) процессов. Рассматриваются подходы к организации управления сквозными процессами в масштабах компании.
Глава 3 раскрывает подход к построению системы бизнес-процессов. В ней читатель узна́ет о наиболее популярных методах, найдет практические рекомендации по построению системы процессов компании и примеры.
Глава 4 посвящена вопросам описания процессов на операционном уровне. Обсуждаются часто используемые методики моделирования, вопросы создания электронного репозитория компании. Приводятся примеры схем бизнес-процессов в формате Work Flow.
В главе 5 подробно описаны построение в организации системы стандартизации бизнес-процессов, плюсы и минусы регламентации. Рассмотрены процедуры управления жизненным циклом нормативно-методических документов и автоматическая генерация регламентов при помощи современных систем бизнес-моделирования.
Глава 6 посвящена определению процессов управления и разработке показателей для управления процессами. Приводятся примеры показателей. Обсуждаются вопросы мониторинга процессов и выполнения корректирующих действий, совершенствования процессов на основе цикла PDCA.
Надеюсь, что книга принесет пользу как собственникам и руководителям компаний, так и специалистам подразделений организационного развития, бизнес-аналитикам, специалистам по менеджменту качества.
Глава 1
Процессный подход: концепция внедрения в организации
1.1. Зрелость компании в области процессного управления
Чтобы успешно внедрить процессный подход к управлению, руководители компании должны четко понимать, в чем заключается процессное управление, как будут выделяться и управляться процессы организации, почему такой подход эффективен. Концепция должна восприниматься не только интуитивно, но и формулироваться в конкретных терминах:
бизнес-процесс (процесс);
архитектура процессов;
владелец процесса;
описание процесса;
регламентация процесса;
стабильность процесса;
улучшение процесса;
автоматизация процесса и т. д.
Пример. Президент одной компании очень увлекался процессным управлением и гордился своими достижениями на этом фронте. Однажды к нему в офис пришел консультант по управлению. Президент рассказывал про свою «процессную работу» и отметил, что у него «каждый сотрудник знает, что такое процесс». Консультант предложил проверить.Руководителю организации важно не только самому проникнуться идеей процессного управления, но и донести свою убежденность до сотрудников. Именно поэтому исключительно важны система терминов и концепция внедрения. Опыт показывает, что успеха добивались те компании, руководители которых создали собственную логичную и понятную концепцию внедрения процессного подхода и, прикладывая в течение нескольких лет немалые усилия, сумели ее реализовать. Важно создать систему управления, неотъемлемой частью которой станет управление процессами. Такую систему невозможно внедрить в приказном порядке или купить (например, в виде какой-либо автоматизации). Вопрос, скорее, в создании определенной культуры работы с процессами на всех уровнях управления.
Вместе с президентом они прошлись по офису и заглянули в одну из комнат. Президент спросил у сотрудника: «А скажи-ка нам, что такое процесс?» Тот подскочил и четко выпалил: «То, что имеет вход и выход!»
Еще пример. Сотрудники одной из компаний на вопрос, внедрен ли у них процессный подход, ответили: «Да, конечно. Еще три года назад мы описали процессы и распечатали регламенты. С тех пор они хранятся вон в том шкафу…»
В главе 1 приводятся необходимые термины и определения, а затем обсуждается концепция внедрения процессного управления. Руководители организаций могут использовать материалы этой главы для уточнения собственного ви́дения целей и задач внедрения процессного подхода, концепции внедрения, для разработки основных методических документов в области процессного управления .
Глава написана для тех, кто готов положить в основу своей деятельности систему управления, основанную на процессном подходе.
Перед тем как приступить к освоению методов процессного управления, оцените уровень зрелости своей организации. Для этого есть несколько способов, и я приведу пример одной из возможных моделей . Концепция уровней зрелости процесса (Process Maturity Levels) была создана в Институте программной инженерии (Software Engineering Institute, SEI) при Университете Карнеги – Меллона в 1990-е гг. В ее основу положена работа Уотса Хамфри. Впервые разработанная для поддержки анализа зрелости процесса программирования (CMM), последняя версия, интегрированная модель технологической зрелости (Capability Maturity Model Integrated, CMMI), была обобщена для любого из широкого спектра процессов в различных организациях (рис. 1.1.1).
Рис. 1.1.1.
Обзор основных уровней зрелости по модели СММI
Приведу краткое описание каждого из уровней, указанных на рис. 1.1.1.
Уровень 1. Процессы не определены
Организации уровня 1 не используют процессную идеологию. Часто их называют организациями, которые держатся на героях. При выполнении работы сотрудники прилагают героические усилия, чтобы успеть закончить ее вовремя и отчитаться перед руководством. В такой компании невозможно рассчитать, какие ресурсы требуются для выполнения тех или иных процессов.
Уровень 2. Определены некоторые процессы
Впервые обращаясь к процессам, организации, как правило, начинают с попытки определить, какие из них ключевые или наиболее часто используются. На этом этапе руководители не представляют себе компанию целиком как совокупность взаимодействующих процессов, а фокусируются на конкретном процессе. У организаций уровня 2 может быть определено несколько основных процессов.
Уровень 3. Определено большинство процессов
В организациях уровня 3 идентифицирована основная часть процессов. Существуют модели (описания) ключевых бизнес-процессов. У руководства есть понимание того, как ими управлять. В большинстве организаций уровня 3 разработана архитектура (система) процессов. В случае возникновения проблем выявляются процессы, которые их вызывают. Затем анализируются и устраняются причины проблем.
Уровень 4. Процессы находятся под управлением
Организации уровня 4 вышли за пределы простого определения процессов. В них менеджеры проводят мониторинг и анализируют процессы с использованием системы показателей, принимают решения по оптимизации процессов.
Пример. Компания, в которой давно внедрена система бизнес-моделирования, создан и используется репозиторий бизнес-процессов, контролируется исполнение регламентов по процессам, внедрена система управления эффективностью BPM для оперативного мониторинга и управления процессами, относится к уровню 4. В такой компании (а это, скорее всего, крупный, устойчивый бизнес) есть необходимое количество штатных специалистов, профессионально владеющих методами моделирования бизнес-процессов, разработкой и анализом KPI и т. п. Эти специалисты могут осваивать и внедрять сложные методики и инструменты в области управления бизнес-процессами.Уровень 5. Процессы непрерывно совершенствуются
В организациях уровня 5 процессы не только находятся под управлением, но их постоянно совершенствуют.
На каком уровне зрелости находятся российские компании?
Считаю, что большинство российских организаций находится на первом или на втором уровне зрелости, некоторые приближаются к третьему, небольшая часть – к четвертому. Очень мало организаций, работающих на пятом уровне.
На мой взгляд, для определения зрелой с процессной точки зрения организации можно использовать следующие критерии:
наличие и поддержание в актуальном состоянии архитектуры (системы) бизнес-процессов компании (система BPA);
действующая система стандартизации (регламентации) деятельности (в первую очередь процессов); использование системы класса ECM для поддержки жизненного цикла нормативно-методических документов (регламентов, положений, инструкций);
наличие и активное использование для мониторинга, анализа, улучшения и стимулирования системы показателей (метрик) по бизнес-процессам; используется система BI /BPM;
наличие компетентных специалистов в области моделирования, анализа и регламентации бизнес-процессов в каждом функциональном подразделении;
наличие центра компетенции (департамента /отдела) по организационному развитию с представителями в каждом департаменте (функциональное подчинение);
автоматизация наиболее важных сквозных процессов в BPMS .
Рис. 1.2.1.
Структурная схема процесса
1.2. Термины и определения процессного подхода
1.2.1. Структурная схема процесса
На рис. 1.2.1 представлена структурная схема процесса. Она является универсальной и может быть использована для анализа процесса любого уровня, вплоть до элементарных операций. Это базовая схема для понимания сущности процесса как некоторой части деятельности организации.
Процесс включает в себя деятельность по преобразованию ресурсов и деятельность по управлению. Сформулируем определение:
Процесс – устойчивая, целенаправленная совокупность взаимосвязанных видов деятельности, которая по определенной технологии преобразует входы в выходы, представляющие ценность для потребителя (клиента).Проще говоря, процесс – это периодически повторяемая, управляемая деятельность, результатом которой является некоторый ресурс, имеющий ценность для конкретного потребителя (клиента).
Под ресурсом понимается материальный или информационный объект, необходимый для выполнения процесса.С точки зрения состояния ресурсы могут:
храниться;
перемещаться;
находиться в состоянии обработки.
Пример. Товар, привезенный на автомобиле к магазину, разгружают и перемещают в зону приемки. Очевидно, что последовательно меняются такие состояния товара-ресурса, как: перемещение (в автомобиле), перемещение (разгрузка), хранение (зона приемки).Связь ресурса с процессом можно определить при помощи понятий «вход» и «выход». Если какой-либо ресурс нужен для выполнения процесса, то он может рассматриваться как вход с точки зрения данного процесса. А ресурс, преобразованный при выполнении этого процесса и получивший определенную ценность для потребителя, – в качестве выхода. Таким образом, ресурсы движутся, хранятся, перерабатываются. Их можно называть входами или выходами только по отношению к конкретному процессу. Выход одного процесса будет входом для другого. Говорить о входах и выходах безотносительно конкретного процесса не имеет смысла.Пример. Маркетолог приобретает аналитический отчет по исследованию рынка, изучает его и делает определенное заключение по прогнозу объема продаж продукции компании. Данный отчет является информационным ресурсом, который сначала перемещается, потом хранится (в персональном компьютере маркетолога или на его рабочем столе в бумажном виде), потом находится в состоянии обработки (поиск информации в отчете и последующий ее анализ). В результате информация, содержащаяся в отчете, преобразуется в прогноз продаж. Таким образом, отчет нужен для выполнения работы. Этот документ является входом в процесс, осуществляемый маркетологом.
На рис. 1.2.1 показано, что с точки зрения процесса ресурсы могут быть преобразуемыми, преобразованными, обеспечивающими и ресурсами по управлению. Приведу необходимые определения.
Преобразуемый ресурс – тот, который подвергается преобразованию в ходе выполнения процесса.Преобразуемый ресурс поступает на вход процесса. При выполнении процесса ресурс приобретает дополнительную ценность, становится преобразованным и поступает на выход процесса – внутреннему или внешнему потребителю. В свою очередь, потребитель может рассматривать преобразованный ресурс в качестве входа для своего процесса, то есть в качестве преобразуемого ресурса, и т. д.
Преобразованный ресурс – тот, к которому добавлена определенная ценность при выполнении процесса.
Обеспечивающий ресурс необходим для выполнения процесса, но не преобразуется в ходе процесса.
Ресурс по управлению – необходимый для управления процессом.
Вход процесса – преобразуемый ресурс или ресурс по управлению, необходимый для выполнения процесса, поставляемый другими процессами.
Выход процесса – преобразованный при выполнении процесса ресурс.
Для выполнения процесса кроме преобразуемых ресурсов нужны также обеспечивающие ресурсы. К их числу можно отнести оборудование, программное обеспечение, инфраструктуру, сотрудников. Обеспечивающие ресурсы могут:
периодически, по мере необходимости поставляться в процесс другими процессами;
выделяться процессу на постоянной основе.
Пример. Арендованный офис с мебелью, персональными компьютерами и прочим оснащением может рассматриваться в качестве обеспечивающего ресурса, выделенного процессу (владельцу процесса) на постоянной основе. В то же время переговорная комната, предоставленная на основе заявки руководителя на ограниченное время, может рассматриваться как периодически поставляемый (административной службой) обеспечивающий ресурс.Трансформируются ли обеспечивающие ресурсы при выполнении процесса? С точки зрения рассматриваемой модели – нет. В реальной жизни обеспечивающие ресурсы меняются:
сотрудники приобретают опыт работы, стареют и т. п.;
оборудование изнашивается;
программное обеспечение морально устаревает.
Однако при использовании данной модели указанными явлениями можно пренебречь. Напротив, если мы будем описывать и анализировать процессы управления персоналом или процессы технического обслуживания и ремонта оборудования, то изменение обеспечивающих ресурсов – важный фактор. Они являются для таких процессов основными объектами добавления ценности, поступают на выход в качестве преобразованных ресурсов.
Ресурс по управлению представляет собой информацию, необходимую для управления. В зависимости от направления потока это может быть информация фактическая, плановая или содержащая управленческие решения.
Вернемся к рис. 1.2.1. Деятельность по управлению процессом, представленная на схеме, включает улучшение процесса и регулирование процесса (оперативное управление).
Основная задача оперативного управления – поддержание процесса в стабильном воспроизводимом состоянии за счет выявления и устранения причин отклонений (вариаций). В свою очередь, улучшение процесса ориентировано на постоянное, целенаправленное изменение процесса на основе целей, установленных вышестоящим органом управления (на схеме это «Деятельность по управлению на более высоком уровне иерархии»). Поясню: для каждого процесса организации всегда существует
иерархически вышестоящий орган управления.
Чтобы управлять процессом, руководителю нужны полномочия по распоряжению ресурсами и информацией. На схеме показаны так называемые ресурсы по управлению. Они, как правило, представляют собой плановую и фактическую информацию. Например, от вышестоящего органа управления поступают цели и плановые показатели деятельности, при выполнении процесса возникает оперативная фактическая информация и т. д. Руководитель управляет процессом также через информационные воздействия (устные сообщения, информационные письма, распоряжения, приказы).
Они являются выходами деятельности по управлению процессом.
Говоря об управлении процессом, определим понятие «владелец процесса».
Владелец процесса – должностное лицо, которое имеет в своем распоряжении выделенные ресурсы, управляет ходом процесса и несет ответственность за результаты и эффективность процесса.Подход, при котором для каждого выделенного процесса назначается владелец процесса, появился давно . Сейчас существует множество различных взглядов на то, что собой представляет владелец процесса и чем он должен заниматься. Однако чем больше консультанты по управлению рассуждают об этом, тем меньше ясности для практиков – руководителей, которые должны внедрять институт владельцев процессов в компании.
Владельцем процесса, как правило, назначается руководитель структурного подразделения (либо его заместитель, помощник). Существующая в компании иерархия управления структурными подразделениями не разрушается. Какая-либо иерархия владельцев процессов не создается. Уточню: количество ресурсов, переданных в управление владельцу процесса, и его ответственность за результаты процесса могут быть различными. Они меняются в зависимости от типа процесса, его важности для организации и т. д.
В целом владелец процесса – это руководитель, способный как минимум:
проводить мониторинг хода процесса;
анализировать факторы, влияющие на процесс и приводящие к вариациям;
разрабатывать предложения по улучшению процесса и организовывать их обсуждения и согласования;
координировать (или управлять) внутренние проекты совершенствования процесса.
В некоторых компаниях принята двухуровневая схема управления процессами. Владельцы процессов назначаются из числа руководителей верхнего уровня. При этом непосредственной работой с процессами (оперативным мониторингом, анализом отклонений и т. д.) занимаются так называемые ответственные за процесс.
1.2.2. Границы процесса
Понятие границ процесса является важнейшим при внедрении процессного подхода. Подчеркну, что установление границ осуществляется субъективно – путем достижения договоренности между несколькими сторонами (поставщиками и потребителями). Для обсуждения границ процесса нужно сформулировать несколько определений.
Границы процесса – событие (совокупность событий), инициирующее и завершающее процесс.Пусть ресурс «А» является результатом преобразования в некотором процессе (рис. 1.2.2). С точки зрения владельца этого процесса ресурс «А» – выход. С точки зрения владельца процесса-потребителя ресурс «А» – вход. В момент передачи ресурса «А» от одного процесса к другому происходит переход ответственности за этот ресурс между владельцами процессов. Факт движения ресурса, сопровождающийся переходом ответственности, может быть идентифицирован при помощи события. С точки зрения владельца первого процесса это событие завершает процесс, с точки зрения владельца второго процесса – инициирует его. Одно и то же событие может быть сформулировано по-разному при описании границ двух рассматриваемых процессов. Первый владелец скажет, что ресурс «А» передан, а второй – что ресурс «А» получен. Чтобы при описании процессов было удобнее увязывать их в единую систему, лучше определять одно событие и давать ему примерно такую формулировку: «Ресурс “А” передан из процесса 1 в процесс 2» . В любом случае формулировки событий должны быть обязательно согласованы между владельцами процессов при регламентации границ.
Событие – наступление определенной ситуации (времени, перехода ответственности за ресурсы).
Инициирующее событие – событие, при наступлении которого начинается процесс.
Завершающее событие – событие, которым завершается процесс.
Рис. 1.2.2.
Границы процессов
Приведем примеры формулировки событий, связанных с движением материальных ресурсов:
«Товар помещен в зону хранения»;
«Продукция упакована и передана покупателю»;
«Оборудование установлено».
Примеры формулировки событий, связанных с передачей информации:
«Поступил заказ клиента»;
«Факс отправлен»;
«Руководитель дал отмашку».
Последний пример приведен в шутку. С практической точки зрения такая формулировка события недопустима. Лучше сформулировать так: «Поступило распоряжение руководителя приступить к выполнению работы» (желательно в письменной форме или хотя бы по e-mail).
Заметим, что переход ответственности за ресурсы возможен и внутри процесса, по ходу выполнения работы различными сотрудниками. Соответствующие события могут использоваться для определения зон ответственности сотрудников внутри процесса.
Рассмотрим более сложные случаи, когда событие, завершающее один процесс, не является событием, инициирующим другой процесс. Допустим, в одном из подразделений организации сотрудник подготовил отчет и поместил его на сервер. Завершающее процесс событие можно сформулировать так: «Отчет подготовлен и размещен на сервере». Через некоторое время (например, в конце месяца) сотрудник другого отдела скачивает или открывает на сервере и использует необходимую информацию. Событие, инициирующее его процесс, казалось бы, можно зафиксировать как «Получен отчет такой-то». В реальности отчет мог пролежать на сервере несколько дней до того момента, пока им воспользовались. Как быть? Ответ в формулировке события, инициирующего второй процесс. Это можно сделать так: «Наступил срок подготовки сводного отчета». Далее сотрудник проверяет наличие отчета на сервере. Результат – следующее событие: «Отчет такой-то присутствует на сервере». Очевидно, что определение такого типа событий зависит от степени детализации при описании процесса.
Еще пример: рассмотрим отправку какого-либо документа по корпоративной электронной сети. Факт отправки документа сотрудником можно описать событием «Документ отправлен по e-mail». Однако сотрудник, которому отправлен данный документ, может его получить не сразу или вообще не получить (сбой сети, случайное удаление и т. п.). Значит, инициировать процесс второго сотрудника будет событие «Получен документ по e-mail». Очевидно, что это два разных события. В данном случае можно:
Антон Тимохин , руководитель проектов отдела развития бизнес-систем НПО «ЭЛСИБ»
- выполнение ненужных (не добавляющих ценность) работ, большая вариабельность циклов работ;
- отсутствие стандартизации и унификации бизнес-процессов, произвольная структура бизнес-процессов, отсутствие документации, регламентирующей их выполнение;
- неэффективная архитектура информационных потоков (сбор, анализ, хранение данных), недостаточный уровень автоматизации;
- избыточное число подразделений и департаментов, дублирование функций, неэффективное взаимодействие между ними;
- размытие зон ответственности, отсутствие ответственного за бизнес-процесс и его результат в целом;
- концентрация всех полномочий на высшем уровне иерархии, отсутствие практики делегирования полномочий;
- излишние трудозатраты на контрольно-отчетную деятельность, существенные потери времени на согласованиях;
- система оценки труда не мотивирует сотрудников к снижению затрат и повышению качества, мотивационные показатели подконтрольны мотивируемому.
Список можно продолжить.
Получив по итогам диагностики сигнал о том, что в компании существуют такого рода проблемы, руководитель может сделать вывод – «нам нужно описать и оптимизировать наши процессы, и это поможет нам избавиться от всех проблем». При этом четкой задачи и критериев оптимизации не формулируется. Такой подход к постановке задачи на проект сам по себе имеет несколько проблемных зон, которые неизбежно приведут к негативным последствиям, а вероятность получения положительного результата минимальна:
- Слепая вера топ-менеджмента компании в то, что внедрение новой программной системы (ERP, CRM, MRP и др.), которая (по заверению ее разработчиков) после внедрения и использования лучших практик, заложенных в референтных моделях, совершит чудо и бизнес сам начнет изменяться в положительную сторону… .
- Сложившийся факт, что описание бизнес-процессов многими рассматривается как универсальный инструмент решения проблем. Но на практике это далеко не так – описание может помочь в устранении проблемных зон, но не само по себе, а в рамках комплексного подхода, одним из компонентов которого может быть как раз формализация бизнес-процессов компании.
- Отсутствие бизнес-задачи. Компания работает, приносит некоторую прибыль. Да, при этом есть некоторые сложности в коммуникациях, но не более чем «рабочие моменты». Зачем менять сложившуюся практику выполнения работ, тем более что описание бизнес-процессов потребует инвестиций в программное обеспечение, обучение специалистов, отвлечение сотрудников от рабочего процесса? Снижение эффективности компании и увеличение издержек неизбежно, если в цели проекта не входит увеличение бизнес-показателей.
Несколько слов об оптимизации
Описание бизнес-процессов в большинстве случаев воспринимается как «лекарство от всех болезней», но мало кто из руководителей задумывается о том, зачем необходимо описывать существующие бизнес-процессы? Ведь круг проблем, которые могут быть решены простой формализацией процессов ограничен, а в остальных случаях требуется оптимизация бизнес-процессов компании.
Как правило, к оптимизации относятся как к некоторому абстрактному понятию, не несущему никакой другой нагрузки, кроме эмоциональной: «теперь мы решим все проблемы», при этом, не уделяя никакого внимания критериям оптимизации – какой процесс, насколько улучшить и в каких допустимых пределах.
Если с определением направлений улучшений обычно затруднений не возникает (например, «необходимо сократить время выполнения процесса согласования заявки заказчика»), то с определением и оцифровкой показателей улучшений возникают проблемы. Во многих компаниях не используются системы сбалансированных показателей, и определить «насколько улучшить» становится невозможным, т.к. показатели, характеризующие функционирование конкретного процесса, не определены и не рассчитываются. Таким образом, измерение улучшений зачастую происходит субъективно, «по ощущениям».
Отдельный момент – установление допустимых пределов для изменений. Не секрет, что руководитель или собственник компании на этапе начала работ по совершенствованию устанавливает ряд ограничений и запретов, сводя своими действиями оптимизацию на уровень косметических изменений, неспособных что-либо кардинально улучшить в сложившейся ситуации.
Про инструменты и методологии
Как правило, вопросу выбора инструментов и методологий при инициации работ по формализации бизнес-процессов уделяется минимум внимания. Подразумевается, что нет большой разницы в том, какие системы бизнес-моделирования и какие методологии использовать. Тем не менее, определяющим фактором в вопросе выбора программного обеспечения и методологии должны быть цели, которые планируется достигнуть при реализации проекта по описанию и оптимизации бизнес-процессов.
В зависимости от поставленных целей, фазы развития организации и состояния системы управления можно выделить два подхода к формированию бизнес-модели компании:
· выделение и описание набора отдельных бизнес-процессов компании – позволяет в сжатые сроки выявить причинно-следственные связи и временную последовательность выполнения действий, формализовать процессы и процедуры с акцентом на определение участников, исполнителей, начальных и конечных событий, последовательность действий, движение потоков объектов;
· создание комплексной модели бизнес-процессов – позволяет создать комплексную непротиворечивую бизнес-модель компании с акцентом на создание описания системы, выделение и описание объектов управления.
Данные подходы не являются взаимоисключающими, опыт показывает, что возможны ситуации, когда необходимо решение задач как описания системы в целом, так и описания отдельных (локальных) бизнес-процессов. В данном случае следует двигаться от общего к частному: сначала создавать модель системы в целом и только потом, используя ее как базис, формировать модели отдельных бизнес-процессов.
Вопрос выбора программного обеспечения обычно относится к узкоспециальным и часто передается для решения специалистам ИТ-подразделений с минимальным участием руководителя компании. Тем не менее, не стоит забывать, что методики и инструменты описания бизнес-процессов специализированы и не подходят для решения задач, для которых они не предназначены. Попытка использования для формирования комплексной модели бизнес-процессов выбранной техническими специалистами системы, предназначенной для описания алгоритмов и взаимосвязей операционного уровня, с большой долей вероятности потребует дополнительных финансовых затрат на доработку системы, сделает выполнение задачи сложным, длительным по срокам или просто невозможным.
Что можно получить в итоге
В большинстве случаев руководитель компании, инициируя проект по описанию бизнес-процессов, не учитывает все то, что было описано выше, а сама идея реализации подобного проекта получена им откуда-то извне.
В сложившейся ситуации формулировка задачи на проект сводится к «нам необходимо в сжатые сроки описать бизнес-процессы нашей компании». Если попытаться определить данную необходимость и задать несколько уточняющих вопросов, то ответ скорее будет логически не связанным с поставленной задачей.
Следующим шагом в компании создается структурное подразделение, в штат которого входят аналитики, или принимается решение о привлечении сторонних консультантов для реализации проекта. Возможные варианты дальнейшего развития событий следующие:
· Исполнитель (аналитики компании или внешние консультанты), не задавая лишних вопросов, добросовестно приступают к выполнению работ по проекту. При этом т.к. четких указаний, что описывать, на этапе начала работ не было, описываются либо все процессы подряд, либо те, которые определяет руководитель компании. Дни проходят один за другим, проект, казалось бы, успешно реализуется, вот только полученный результат не оправдывает вложенных средств.
Бизнес-процессы описаны так, как это действительно происходит в компании, полученные модели сложные, запутанные и зачастую не пригодны для дальнейшего использования. Несмотря на это исполнитель предпринимает попытку оптимизации процессов, но в силу недостаточного опыта работы в компании, используя мнение узкого круга лиц, не принимая во внимание взаимосвязи между процессами, по факту не улучшает ничего.
В результате потрачено значительное количество времени и ресурсов, текущие проблемы бизнеса не решены, а у руководителя появляется негативный опыт, не позволяющий ему вернуться к подобной работе в дальнейшем.
· Исполнитель начинает задавать вопросы, уточняя, зачем необходимо описание бизнес-процессов, какой результат планируется достигнуть, какие критерии оптимизации установлены. На этом этапе может быть получен серьезный негатив от руководства компании, потому что, во-первых, ответов просто нет, а во-вторых, задача описания процессов формальная, не подкрепленная логической цепочкой выводов и подзадач. Выясняется ряд «особенностей» бизнеса, которые неприятны руководителю компании и на которые раньше он «закрывал глаза»:
Вдруг выясняется, что описание процессов «как есть» невозможно, просто потому, что их в компании нет – деятельность выполняется на основании опыта сотрудников, решения принимаются по ситуации, и даже регулярные процессы выполняются не так, как закреплено в регламентах, а так, как удобно исполнителям;
Бизнес подвержен внешним или внутренним рискам, отсутствуют целевые показатели, система мотивации не способствует повышению качества продукции/ услуг, учет затрат ведется не в полном объеме или отсутствует;
При описании процессов выявляется необходимость проведения существенных изменений в модели бизнеса.
Не стоит забывать про то, что если процессы в ходе описания оптимизированы, то после завершения проекта по описанию и оптимизации бизнес-процессов необходим еще один проект – внедрение новых версий бизнес-процессов в практику применения персоналом компании. Вот только этот проект потребует гораздо больше усилий для того, чтобы изменить сложившиеся годами устои на новые, необычные, разработанные без участия большинства сотрудников.
Таким образом, описание и оптимизация бизнес-процессов – задача, требующая, кроме опыта и знаний аналитиков, личной заинтересованности, готовности к изменениям, четкого понимания необходимости проекта, а также способов достижения установленных целей со стороны руководителя компании. В противном случае, столкнувшись с описанными выше проблемами и вопросами, когда будет необходимо внести изменения в действующий бизнес – проект закончится, не успев начаться.
Лучшие практики
Задачи описания бизнес-процессов сегодня актуальны для многих крупных российских компаний, независимо от отраслевой принадлежности. В большинстве случаев для их решения формируются аналитические подразделения, которые создают модели действующего бизнеса, отражающие особенности функционирования внутренних бизнес-процессов.
Формирование полноценной бизнес-модели компании – высокотрудоемкая задача, требующая внимательной проработки ключевых этапов до начала работ. Бизнес-задача, сетевой график, отчетность и регламентация, глубина и методология описания – базовые вопросы, которые должны быть решены до начала работ, иначе полученный результат не оправдает ожидания.
Настоящий раздел содержит рекомендации по подготовке и реализации проекта по описанию и оптимизации бизнес-процессов. Раздел подготовлен на основании личного опыта автора статьи по итогам реализации проекта на предприятии энергетического машиностроения, а также с учетом лучших практик других компаний, примененных в ходе выполнения работ.
Допущения: проект реализован силами внутреннего аналитического подразделения компании, специалисты подразделения имеют опыт реализации проектов в области организационного развития, на момент начала работ в компании функционирует система менеджмента качества, в качестве системы бизнес-моделирования используется система Business Studio.
Этап первый – инициация проекта
Для реализации проекта формируется группа управления проектом, назначается куратор проекта, издается приказ о начале работ по описанию и оптимизации бизнес-процессов компании.
Куратором проекта рекомендуется назначать должностное лицо из числа заместителей генерального директора, руководителей департаментов, реализующих функции, связанные с развитием компании. Куратор должен быть наделен всеми необходимыми полномочиями для решения вопросов, связанных с выполнением работ по проекту.
Группа управления проектом включает в себя специалистов-аналитиков, которые образуют в дальнейшем Центр компетенции по бизнес-процессам компании. Если в компании внедрена и функционирует система менеджмента качества или интегрированная система менеджмента, специалисты подразделения, реализующего данные функции, также должны быть включены в группу управления проектом. Это позволит использовать накопленную базу знаний по процессам и проблемным зонам, интегрировать функции по описанию, оптимизации и внутреннему аудиту бизнес-процессов. Также в состав групп включаются технические эксперты по различным направлениям деятельности для получения экспертных мнений и оперативного решения спорных вопросов по функционированию отдельных процессов
Этап второй – бизнес-задача
На начальном этапе работ по описанию и оптимизации бизнес-процессов группой управления проектом должна быть проведена организационная диагностика. Цель - определение недостатков в работе компании, проблемных зон и причин неэффективности бизнес-процессов; повышение качества планирования работ по проекту.
Диагностика может проводиться классическим способом (интервьюирование, стратегическая сессия, анализ показателей эффективности) или с применением онлайн-системы BIZDIAGNOSTICS. Система BIZDIAGNOSTICS – управленческий инструмент, который позволяет быстро и с минимальными ресурсными затратами провести внутренний аудит компании и получить достоверную и объективную информацию о качестве системы управления компании, идентифицировать проблемные зоны и получить рекомендации по их устранению. Результаты организационной диагностики являются основой для формулирования бизнес-задачи на проект.
Типовой ошибкой является описание бизнес-процессов ради самого описания. Подобный подход приведет к негативной реакции бизнеса, который не получит значимых результатов после работы аналитиков, т.к. разработанная модель бизнес-процессов сама по себе значимым результатом не является. Это подрывает веру руководителя и топ-менеджмента компании в процессный подход в целом и процессное управление в частности с последующими организационными решениями в части «оптимизации» численности внутренних аналитиков или полной остановки работ в данном направлении.
Для исключения данной ситуации на этапе организации работ необходимо определить потребителя и формализовать его требования к разрабатываемой модели бизнес-процессов. Лучше, если таких потребителей будет несколько. Например:
· структурные подразделения компании, заинтересованные в регламентации и оптимизации своих бизнес-процессов,
· подразделения, реализующие функции по поддержанию функционирования и развития систем менеджмента (системы менеджмента качества, интегрированной системы менеджмента), т.к. без процессного управления эффективное функционирование систем затруднительно.
· IT-подразделения, для которых модель процессов упрощает определение алгоритмов работы и формализацию требований к внедряемым информационным системам.
Требования потребителей также позволяют установить набор документов, которые будут формироваться на основе разработанной бизнес-модели компании. Это позволит определить информацию, (например, данные необходимые для проведения функционально-стоимостного анализа), которая должна быть собрана в рамках проекта.
Формализация требований потребителей в виде технического задания позволит исключить большую часть «лишней» работы в проекте, выбрать программный продукт, наилучшим образом соответствующий поставленной задаче, а также получить значимый для бизнеса результат с меньшими временными, финансовыми и трудовыми затратами.
На основании результатов организационной диагностики, технического задания группой управления проектом после проведения сессии с руководителем и топ-менеджментом компании сформулирована бизнес-задача на проект – определены функциональные области для улучшений, критерии оптимизации (что и насколько улучшить), формализованы требования потребителей разрабатываемой модели бизнес-процессов компании. Также в бизнес-задаче должны быть однозначно определены четкие пределы для изменений (какие изменения бизнеса приемлемы, какие недопустимы). После утверждения бизнес-задачи разрабатывается сетевой график реализации проекта.
Этап третий – программное обеспечение
Следующим важным шагом является выбор программного обеспечения, необходимого для успешной реализации проекта – системы бизнес-моделирования.
Система бизнес-моделирования – программный продукт для создания и анализа бизнес-модели компании, проектирования новых бизнес-процессов, разработки и поддержания в актуальном состоянии пакета регламентирующей документации. Система играет большую роль в проекте по описанию бизнес-процессов, т.к. она обеспечивает единое информационное поле для совместной работы аналитиков, предоставляя им необходимый инструментарий для описания, анализа и оптимизации бизнес-процессов.
Выбор программного продукта осуществлялся по следующим критериям:
· возможность выполнения полного комплекса работ по организационному проектированию;
· автоматизированная система сбора и анализа результатов измерений эффективности бизнес-процессов компании;
· автоматическое формирование пакета регламентирующей документации;
· использование популярных нотаций моделирования бизнес-процессов, дружелюбный к пользователю интерфейс, не требующий проведения специализированного обучения пользователей;
· поддержка системы менеджмента качества;
· возможность гибкой настройки системы «под себя» (возможность ввода пользовательских параметров и справочников).
После анализа рынка систем бизнес-моделирования было принято решение об использовании в нашем проекте системы Business Studio, наиболее полно соответствующей установленным критериям.
Этап четвертый – методология
Проект по описанию бизнес-процессов в крупной компании приводит к разработке большого количества моделей процессов. Если представить, что все диаграммы нарисованы по-разному, то полученный результат не будет представлять никакой практической ценности для компании. Именно поэтому важно определить четкие правила моделирования бизнес-процессов в компании. Для этого разрабатывается Соглашение о моделировании бизнес-процессов – документ, определяющий методологию описания бизнес-процессов, порядок взаимодействия участников процесса описания и оптимизации бизнес-процессов, а также механизмы ввода в действие формируемого пакета регламентирующей документации, поддержания актуального состояния разработанных моделей бизнес-процессов.
Соглашение о моделировании бизнес-процессов определяет используемые нотации моделирования, количество уровней декомпозиции (уровней последовательного разделения бизнес-процесса на составляющие подпроцессы для получения более детального представления), взаимосвязь моделей процессов между собой, пакеты формируемой документации, устанавливает правила работы с объектами и справочниками в системе бизнес-моделирования, определяет параметры, подлежащие заполнению в системе. После ввода в действие данного документа группа управления проектом обязана контролировать его соблюдение всеми сотрудниками компании, вовлеченными в проект по описанию и оптимизации бизнес-процессов. Это обеспечит унификацию разрабатываемых моделей, сведет к минимуму временные затраты на устранение возникающих «ошибок», в т.ч. при работе в системе бизнес-моделирования, позволит получить пакет регламентирующей документации, наиболее соответствующей требованиям потребителей описания бизнес-процессов.
При определении уровней декомпозиции бизнес-процессов следует акцентировать внимание на требованиях потребителей описания бизнес-процессов, их обоснованности, необходимости и достаточности детализации при описании. Очень часто модели бизнес-процессов декомпозируются до уровня отдельных действий сотрудников там, где это нецелесообразно. Это приводит к увеличению количества разрабатываемых моделей, значительному росту трудоемкости без увеличения ценности моделей для развития бизнеса, т.к. излишняя детализация не всегда дает информацию для оптимизации процессов.
Практика показывает, что каждый новый уровень декомпозиции увеличивает объем моделей на порядок. Поэтому, если необходимо оптимизировать процессы и определить зоны ответственности между структурными подразделениями компании, следует ограничиться детализацией до уровня подразделений. Выход на уровень элементарных действий применяется, только если модель разрабатывается для целей автоматизации или регламентации деятельности отдельных исполнителей.
Начиная проект, вместе с определением требований его потребителей, необходимо установить, какие элементы окружения необходимо описать. Среди предметных областей, подлежащих формализации, следует выделить:
· организационную структуру,
· информационные системы, поддерживающие выполнение бизнес-процессов,
· носители информации, используемые в процессах.
В ряде случаев формируемую модель могут дополнять показатели эффективности, требования к информационным системам и т.п. Таким образом, бизнес-модель, кроме собственно описания процессов, интегрирует в себе различные предметные области, что значительно повышает ее практическую ценность для дальнейшего анализа и оптимизации.
Этап пятый – бизнес-модель, рабочие группы
Дальнейшая схема выполнения проекта подробно представлена на рисунке 1.
Рисунок 1. Схема выполнения основной фазы проекта по описанию и оптимизации бизнес-процессов
Итак, следующий шаг - разработка модели бизнес-процессов верхнего уровня. Она позволяет получить единый взгляд на устройство бизнеса. Формирование модели лучше проводить с акцентом на создание ценности, используя принципы определения и построения цепочек создания ценности. Разработка модели проводится в формате стратегической сессии или деловой игры с участием руководителя и топ-менеджмента компании. Для разработки модели бизнес-процессов верхнего уровня наиболее удобно использовать нотацию IDEF0.
При разработке модели рекомендуется использовать информацию по структуре бизнес-процессов компаний аналогичной отрасли, отраслевые референтные модели. Готовая модель должна системно показать бизнес-процессы верхнего уровня компании, а также наиболее важные взаимосвязи между ними, необходимые для понимания функционирования бизнеса.
На основании утвержденной бизнес-модели происходит назначение владельцев бизнес-процессов (с ориентацией на действующую организационную структуру компании), а также формирование рабочих групп по описанию и оптимизации бизнес-процессов по каждому из бизнес-процессов верхнего уровня. В целях регламентации деятельности владельцев бизнес-процессов, определения полномочий и разграничения ответственности разрабатывается Должностная инструкция владельца бизнес-процесса. Цель – установление ответственности за результат процесса, определение должностных обязанностей, а также полномочий для распоряжения ресурсами, необходимыми для выполнения процесса.
В рамках проекта владельцы бизнес-процессов отвечают за обеспечение выполнения работ по:
· описанию и оптимизации своих бизнес-процессов,
· выработке предложений по оптимизации бизнес-процессов,
· анализу и согласованию предложений по оптимизации бизнес-процессов, сформированных участниками рабочих групп.
Группой управления проектом совместно с владельцами бизнес-процессов проводится формирование рабочих групп по описанию бизнес-процессов верхнего уровня. В состав групп включаются руководители и специалисты структурных подразделений компании, имеющие в силу своего опыта работы в компании или состава должностных обязанностей достаточное представление о бизнес-процессе, подлежащем описанию и оптимизации. Рабочие группы возглавляет руководитель рабочей группы. Он назначается из числа руководителей структурных подразделений, принимающих участие в выполнении соответствующего бизнес-процесса. Численность рабочей группы варьируется в зависимости от «объема» и сложности конкретного бизнес-процесса.
В рамках проекта на участников рабочих групп возлагаются обязанности по разработке модели бизнес-процессов, подготовке предложений по оптимизации бизнес-процессов, подготовке и проведению согласования разработанного пакета регламентирующей документации. Для эффективного выполнения работ по проекту рабочее время участников групп распределяется в соотношении 30/70 (проект/ должностные обязанности) приказом руководителя компании.
После выполнения всех вышеперечисленных подготовительных мероприятий и установки системы бизнес-моделирования на рабочие станции пользователей проводится обучение участников рабочих групп и, при необходимости, руководителей среднего и высшего звена компании методикам и принципам описания и оптимизации бизнес-процессов. Обучение рекомендуется разделять на теоретическую (для всех) и практическую (для участников рабочих групп) части. Большее время необходимо уделять практике описания бизнес-процессов и работе с системой бизнес-моделирования, отрабатывая на простых примерах навыки работы и демонстрируя «классические» ошибки.
Обучение может проводиться как сторонней организацией, так и членами группы управления проектами при наличии достаточных компетенций и опыта работы с используемой системой бизнес-моделирования.
Этап шестой – моделирование, оптимизация
После обучения рабочими группами проводится анализ деятельности структурных подразделений, идентификация и структурирование бизнес-процессов, которые в них выполняются. Информация вносится в дерево процессов системы бизнес-моделирования с указанием наименования процесса, руководителя, ответственного за его выполнение, участников, инициирующих/ завершающих событий и результатов.
После идентификации процессов в формате деловой игры проводится перекрестное согласование процессов, представляющих собой 1-й уровень декомпозиции бизнес-процессов верхнего уровня, при необходимости производится доработка полученной структуры.
Следующим шагом является установление взаимосвязей между подпроцессами 1-го уровня декомпозиции через входы и выходы, наполнение модели информационными потоками и потоками объектов. Переход на 2-й уровень декомпозиции, введение информации в систему бизнес-моделирования и согласование структуры подпроцессов проводится аналогично.
Чтобы исключить дублирование информации в справочниках системы, на данном этапе в группах по описанию и оптимизации бизнес-процессов назначаются ответственные. Они осуществляют ввод данных в справочники на основании запросов участников группы.
Также в целях повышения эффективности работы групп, структурирования информации в базе данных системы, минимизации временных затрат на поиск информации в системе при вводе данных в справочники группы «Объекты деятельности» рекомендуется создавать структуру каталогов (например так, как это описано в статье «Организация работы с документами на платформе Business Studio»).
После завершения работ на 2-м уровне декомпозиции моделей бизнес-процессов верхнего уровня выполняется согласование границ подпроцессов и бизнес-процессов верхнего уровня по входам/ выходам, началу и результату процесса. Чтобы минимизировать временные затраты на согласование, рекомендуется проводить его в формате деловых игр, построенных по принципу докладов, в которых рабочие группы «моделируют» свой процесс, проговаривают его от момента начала до получения итогового результата, а остальные участники (владельцы процессов, представители группы управления проектом, куратор проекта, технические эксперты) вносят необходимые корректировки. При необходимости в ходе деловых игр участники игры вырабатывают совместные решения по спорным вопросам, возникающим в ходе описания бизнес-процессов. Как правило, в результате согласования происходит корректировка структуры процессов в бизнес-модели компании.
Полученная первая версия бизнес-модели компании подлежит дальнейшей декомпозиции – разрабатываются модели 3-го, 4-го уровня. Согласование данных моделей проводится в формате деловой игры с привлечением владельца процесса, представителей группы управления проектом, владельцев процессов-потребителей результатов бизнес-процесса, технических экспертов. В ходе согласования уточняется движение информационных потоков и потоков объектов, уточняются должности руководителей, ответственных за выполнение процессов, состав участников на уровне структурных подразделений и должностей сотрудников.
После получения второй версии бизнес-модели проводится ее финальное согласование, результатом является третья, основная рабочая версия, которая будет являться базисом корпоративной базы знаний по бизнес-процессам компании. На основе этой базы знаний будут проводиться мероприятия по дальнейшей оптимизации бизнес-процессов или разработке методик и процедур уровня элементарных действий.
Для бизнеса важно получение быстрого результата от вложенных инвестиций. Проект по описанию и оптимизации бизнес-процессов - не исключение, тем более что он направлен на повышение эффективности деятельности компании в целом. Для того чтобы показать значимый результат в приемлемые сроки, на этапе описания бизнес-процессов рекомендуется сформировать предложения по оптимизации бизнес-процессов с использованием инструментов выявления и устранения потерь, принципов и методов оптимизации бизнес-процессов. Предложения по оптимизации бизнес-процессов рассматриваются в ходе деловых игр с участием представителей группы управления проектом, владельцев процессов и всех заинтересованных лиц и, в случае согласования, отражаются в разрабатываемой бизнес-модели.
Этап седьмой – внедрение
После согласования финальной версии модели бизнес-процессов компании деятельность по описанию и оптимизации бизнес-процессов переводится на постоянную основу – как говорилось ранее, группа управления проектом становится Центром компетенций по бизнес-процессам компании, участники рабочих групп по описанию и оптимизации бизнес-процессов продолжают совмещать свою текущую деятельность в структурных подразделениях компании с моделированием, анализом и регламентацией своих бизнес-процессов.
Разработанные модели бизнес-процессов и регламентирующая документация вводится в действие приказом руководителя компании. Информация доводится до сотрудников в соответствии с правилами, установленными в компании, а также с использованием HTML-навигатора, размещенном на корпоративном сетевом ресурсе.
Соблюдение требований введенных в действие регламентов и процедур проверяется в ходе внутренних аудитов, проводимых внутренними аудиторами (если в компании действуют системы менеджмента) или специалистами внутреннего аналитического подразделения. Порядок и сроки проведения аудитов устанавливаются соответствующим регламентирующим документом. Эффективность деятельности компании оценивается по результатам организационной диагностики, а также по данным мониторинга показателей эффективности бизнес-процессов.
Практика показывает, что на момент начала работ по описанию и оптимизации бизнес-процессов в компаниях уже имеется большой пакет регламентирующей документации (особенно характерно для компаний, в которых действуют системы менеджмента) Часть документов из данного пакета зачастую нецелесообразно переносить в систему бизнес-моделирования для будущего формирования в автоматическом режиме ввиду больших временных и трудозатрат. Для синхронизации имеющихся документов с новыми версиями процессов компании на этапе описания процессов необходимо проводить их анализ на предмет актуальности. После согласования финальной версии бизнес-модели выполняется полная актуализация имевшейся документации с привязкой к новым версиям бизнес-процессов.
Вместо заключения
Резюмируя вышесказанное, хочется отметить, что, как и в любом сложном деле, при улучшении деятельности компании важно точное понимание причин инициирования проекта и использование в проекте наилучших методик и инструментов, Надеемся, что эта статья снимет множество вопросов, которые возникают у руководителей, и позволит легче решиться на начало изменений. Уверены, что результат не заставит себя ждать!
Бизнес-процессы. Моделирование, внедрение, управление Репин Владимир Владимирович
Внедрение среды моделирования процессов в масштабах организации – важный и сложный проект. Для его успешного выполнения нужно разработать план, адекватный задаче. Предлагаю один из возможных вариантов такого плана.
Для крупной компании внедрение среды моделирования – серьезный проект, который может состоять из трех этапов:
1. Выбор и тестирование среды моделирования.
2. Опытная эксплуатация среды моделирования.
3. Внедрение среды моделирования в масштабах компании.
Этап 1. Выбор и тестирование среды моделирования:
Определение потребностей внутренних пользователей;
Определение и согласование целей и задач проекта;
Анализ сред моделирования, представленных на рынке (по документации), и выбор системы для тестирования;
Установка пробной версии среды моделирования (два-три рабочих места);
Создание пилотной модели организации:
– описание двух-трех процессов на двух уровнях;
– описание фрагмента организационной структуры;
– описание некоторых документов, терминов, ТМЦ;
– формирование пилотных отчетов (регламентов выполнения бизнес-процессов);
Тестирование среды моделирования на основе пилотной модели:
– тестирование функциональных возможностей системы;
– тестирование выгрузки отчетов (регламентирующих документов);
– тестирование управления изменениями;
Анализ результатов тестирования среды моделирования на пилотной модели, принятие решения о выборе системы;
Определение конфигурации системы, необходимой для решения задач организации;
Принятие решения и закупка среды моделирования;
Установка системы (три-пять конкурентных лицензий);
Обучение группы специалистов работе со средой моделирования (включая прохождение теста и получение официальных сертификатов);
Разработка детального плана опытной эксплуатации среды моделирования.
Этап 2. Опытная эксплуатация среды моделирования:
Администрирование системы:
– создание групп пользователей и определение прав доступа;
– настройка функционала контроля внесения изменений в систему;
Анализ и внесение необходимых изменений в метамодель:
– анализ требований внутренних потребителей по выгрузке отчетов из среды моделирования (регламенты, положения, прочие отчеты);
– анализ возможностей метамодели с точки зрения хранения информации, необходимой для выгрузки отчетов;
– определение и внесение необходимых дополнений в метамодель (структуру данных);
– определение требований по использованию метамодели при моделировании организации;
Ввод в систему необходимых справочников:
– иерархический справочник процессов организации (возможно, путем импорта системы процессов организации из файла MS Excel);
– иерархический справочник подразделений и должностей;
– справочник бумажных и электронных документов (уровня компании);
– справочник терминов;
– прочее.
Разработка и тестирование необходимых шаблонов регламентирующих документов и других отчетов;
Разработка решений по интеграции с другими системами («экспорт – импорт»);
Разработка стандарта моделирования (нормативный документ, регламентирующий использование функционала системы и метамодели при описании процессов, подразделений, документов и т. п.);
Разработка и тестирование регламента управления изменениями (нормативный документ, регламентирующий взаимодействие сотрудников и порядок внесения изменений в объектную модель организации);
Анализ эффективности функционирования среды моделирования; внесение необходимых изменений в регламенты работы с системой.
Этап 3. Внедрение среды моделирования в масштабах компании:
Определение количества необходимых лицензий;
Закупка и установка среды моделирования в структурных подразделениях организации;
Обучение руководителей и специалистов подразделений использованию системы (соглашение по моделированию, регламент управления изменениями и т. д.);
Разработка плана описания процессов организации;
Описание приоритетных процессов организации силами специалистов подразделений; выгрузка регламентирующих документов;
Анализ эффективности эксплуатации среды моделирования, внесение необходимых изменений в регламенты работы с системой.
В стандарте по моделированию сформулированы требования по использованию системы при описании процессов, подразделений, документов и т. п. Это подробная инструкция, в соответствии с требованиями которой сотрудники организации обязаны работать со средой моделирования: заносить информацию в соответствующие атрибуты объектов модели, формировать графические схемы и т. д. Документ может иметь такую структуру (на примере стандарта, разработанного для использования среды Business Studio):
1. Общие положения
1.1. Назначение и область действия
1.2. Используемые сокращения
1.3. Термины и определения
2. Ведение справочников в Business Studio
2.1. Справочник «Процессы»
2.2. Справочник «Субъекты»
2.3. Справочник «Объекты деятельности»
2.4. Справочник «Управление»
3. Описание процессов в Business Studio
3.1. Элементы нотации «Процедура» Business Studio
3.2. Описание операций процесса
3.3. Использование стрелок типа «Связь предшествования»
3.4. Использование стрелок типа «Поток документов»
3.5. Использование событий
3.6. Использование блока «Решение»
3.7. Использование междиаграммных ссылок
3.8. Использование сносок
4. Схемы организационной структуры в Business Studio
4.1. Используемые графические элементы
5. Заполнение атрибутов объектов модели
5.1. Заполнение атрибутов процесса
5.2. Заполнение атрибутов операции процесса
5.3. Заполнение атрибутов стрелок
5.4. Заполнение атрибутов субъекта деятельности
5.5. Заполнение атрибутов объекта деятельности
5.6. Заполнение атрибутов целей и показателей
6. Приложения
6.1. Пример схемы процесса в нотации «Процедура» Business Studio
Регламент управления изменениями – это инструкция по внесению существенных изменений в систему, в том числе изменение модели организационной структуры, изменение справочника процессов на верхнем и среднем уровне, массовое переназначение ответственности за выполнение процессов. Подобные действия могут выполнять только квалифицированные бизнес-аналитики, имеющие соответствующие полномочия. Регламент может выглядеть примерно так:
1. Общие положения
1.1. Назначение
1.2. Термины, определения и сокращения
2. Общее описание процесса управления изменениями
3. Типы изменений и распределение ролей и ответственности за управление изменениями
4. Изменения справочников
4.1. Организационная структура
4.2. Процессы
4.3. Объекты деятельности (документы, ТМЦ, программные продукты)
4.4. Цели и показатели
4.5. Прочее
5. Изменение схем процессов
6. Изменение шаблонов отчетов
7. Изменение метамодели
8. Архивирование и восстановление объектной модели
9. Изменение прав доступа
10. Изменение версии системы (переход на новые версии)
11. Изменение решений по интеграции с другими системами
В заключение приведу пример графика проекта по созданию репозитория бизнес-процессов организации на платформе среды моделирования Business Studio (рис. 4.10.1).
Рис. 4.10.1. График Ганта создания репозитория бизнес-процессов на платформе среды моделирования Business Studio
После покупки и установки системы Business Studio следует обучить рабочую группу. Несколько специалистов из нее образуют потом центр компетенции по использованию репозитория бизнес-процессов. Остальные будут совмещать текущую деятельность в подразделениях с моделированием, анализом и регламентацией бизнес-процессов. Они станут агентами влияния процессной методологии в структурных подразделениях компании.
Для эффективного использования системы нужно разработать архитектуру (систему) бизнес-процессов компании. Удобно это делать в MS Excel, но можно и сразу в системе. Далее полученная архитектура процессов переносится в Business Studio – создается иерархический справочник процессов. Этот справочник – основа для накопления знаний о процессах в рамках электронного репозитория.
Затем рабочая группа описывает несколько пилотных процессов. Это делается для того, чтобы в полной мере освоить возможности инструмента и сформулировать предварительные требования к стандарту моделирования и шаблонам регламентирующих документов.
Чтобы выгрузить из репозитория информацию о процессах в необходимой форме (регламенты, инструкции, положения и т. п.), нужно определить требования к этим документам. При проектировании шаблонов отчетов увязываются между собой требования к документам и возможности системы. Например, если мы хотим видеть в документе какой-то атрибут бизнес-процесса, надо понимать, какую информацию и как следует заносить в репозиторий. Создание шаблонов для выгрузки сложных регламентирующих документов может потребовать изменений объектной модели Business Studio. Это легко делается при помощи специального инструмента Meta Edit, входящего в комплект поставки системы (в версии Enterprise).
Когда станет понятно, как моделировать процессы и какая информация должна заноситься в атрибуты объектов модели, разрабатывается стандарт моделирования (соглашение по моделированию).
Кроме этого документа полезно создать стандарт (инструкцию) по администрированию репозитория и стандарт по внесению изменений в модель организации.
После разработки и согласования стандартов проводится обучение руководителей и специалистов подразделений компании работе с электронным репозиторием бизнес-процессов на платформе Business Studio.
Из книги Человеческий фактор в программировании автора Константин Ларри Л Из книги Инструменты McKinsey. Лучшая практика решения бизнес-проблем автора Фрига ПолУказания по внедрению Как мы сказали в начале этой части, развитие – это постоянный цикл. Получив задание следить за развитием другого сотрудника, вы должны ставить для своего подопечного цели, соответствующие и его личным потребностям в совершенствовании, и
Из книги Виртуальные организации. Новая форма ведения бизнеса в XXI веке автора Уорнер МалкольмУказания по внедрению Пора вернуться к нашей команде из Acme Widgets. Лукас, недавно назначенный менеджером по закупкам в подразделение малярных кистей (как помните, вы искали этого сотрудника в главе 6), только что прошел вводный курс обучения и готов приступать к работе. К
Из книги Бизнес-процессы. Моделирование, внедрение, управление автора Репин Владимир ВладимировичУказания по внедрению Такая актуальная тема, как изменение границ организаций, сегодня активно обсуждается и на заседаниях советов директоров, и в классах учебных заведений. Некоторые заявляют, что дни массивных организаций сочтены, так как теперь специалисты по работе
Из книги Проектируем корпоративную архитектуру автора Кондратьев Вячеслав ВладимировичТехнологии моделирования Пока еще не очень популярные технологии моделирования представляют собой сложное программное обеспечение, которое позволяет менеджерам создавать модели систем для их исследования и анализа, а также их модификации - для изучения
Из книги Прорыв в бизнесе! 14 лучших мастер-классов для руководителей автора Парабеллум Андрей Алексеевич4.2.2. Нотация моделирования процессов Руководителям нужно определиться с требованиями к описанию процессов, в том числе выбрать нотации для создания моделей. Следует выявить внутренних потребителей и понять их запросы. Например, руководителям подразделений нужно
Из книги Хватит платить за все! Снижение издержек в компании автора Гагарский Владислав4.2.3. Репозиторий и среда моделирования процессов Представьте, что вам поручили разработать регламент выполнения какого-то процесса компании. Ситуация складывается удачно – у вас стоит MS Visio. Вы создаете новый файл, начинаете рисовать схему процесса, затем сохраняете
Из книги Руководство по улучшению бизнес-процессов автора Коллектив авторов4.4. Архитектура типовой среды моделирования процессов Сейчас на рынке представлено множество программных продуктов для моделирования деятельности организации. Эти продукты относятся к так называемым средствам Business Process Architecture или Enterprise Architecture, то есть программным
Из книги Управление бизнес-процессами. Практическое руководство по успешной реализации проектов автора Джестон Джон4.6.5. Нотация «Процедура» среды моделирования Business Studio Сейчас одним из распространенных инструментов бизнес-моделирования стала среда Business Studio. В этой системе реализованы четыре нотации: IDEF0, «Процесс», «Процедура», eEPC.Нотация IDEF0 используется для построения моделей
Из книги автора5.1.7. Регламентация процессов производства при отсутствии регламентации процессов управления/развития В ряде компаний регламентация процессов производства достигает 90–100 %, то есть регламентирована почти вся деятельность. Внешние требования (ограничения)
Из книги автора19. Методологии и программные решения для моделирования структур и процессов 19.1. Эволюция представлений о моделировании бизнес-процессовПервоначально методологии и программные решения по моделированию бизнес-процессов были сфокусированы на отдельных важных, но
Из книги автораПроблемы моделирования При копировании чужих моделей важно на стадии тестирования убедиться, что они действительно успешны, а не кажутся такими.Многие копируют внешние элементы той или иной системы, не понимая ее внутренних закономерностей.Серьезной проблемой
