Лекции_Управление БП. Тема Понятие, сущность и классификация бизнеспроцессов
 Скачать 4.71 Mb.
|
|
Тема 6. Проектирование процессов как часть управления процессами Учитывая, что процесс – совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующих входы в выходы, то и информационные потоки претерпевают изменения: входные показатели (документы) превращаются в выходные показатели (документы), которые характеризуют результат процесса. Проектирование (process design) процессов является частью процессного управления (process management), которое в свою очередь включает в себя также: 1. Process Modeling – Моделирование процессов; 2. Process Analysis – Анализ процессов; 75 3. Process Performance Management – Управление эффективностью процессов. (Рисунок 6.1) Прежде чем рассматривать вопрос о проектировании процессов, которые в дальнейшем лягут в основу создаваемых информационных систем, необходимо отметить назначение моделирования процессов и их анализа. По большому счету самим разработчикам ИС неважно какой процесс будет реализован в ИС, в тоже время преобразование процесса из состояния «как есть» в состояние «как должно быть» является важным для владельца этого процесса. Рисунок 6.1 — Процессное управление Процессы проходят в организациях и на предприятиях, которыми руководят директора (начальники, заведующие и т.п.), а владеют акционеры и учредители (либо, обезличено, государство), поэтому они одни из первых заинтересованы в эффективности этих процессов. Поэтому для моделирования процессов (бизнес-процессов) можно выделить следующие побудительные причины (Таблица 6.1). [3] Анализ процессов Проектирование процессов Управление эффективностью процессов Моделирование процессов 76 Таблица 6.1 — Побудительные причины моделирования процессов С точки зрения Побудительные причины Бизнеса Экономия средств – сокращение издержек Повышение качества – уменьшение потерь Снижение времени производства Увеличение производительности Сокращение общего времени выполнения заказа (запроса) – удовлетворенность заказчика (потребителя) Обнаружение проблем с целью их устранения Накопление знаний – исключение перебоев Стандартизация работы сотрудников Профессионалов управления бизнес- процессами Решение проблем бизнеса посредством: - описания процесса настолько точно и подробно, насколько необходимо исходя из поставленной задачи; - четкого объяснения процесса целевой аудитории; - выбора уровня детализации и типа модели в зависимости от того, что ожидается от проекта и какую бизнес-проблему требуется решить Организации Модели процессов являются средством: - управления процессами организации; - анализа эффективности процесса; - описания изменений Модели процессов могут: - описывать желаемое состояние процесса; - определять требования к ресурсам, обеспечивающим эффективное выполнение операций (люди, информация, оборудование, системы, финансы и т.п.) Анализа и повышения эффективности Повышение прозрачности и понимание процесса Помощь в обучении сотрудников Оценка соответствия требованиям стандартов и нормативов Прогноз эффективности процесса при изменении нагрузки или других параметров Анализ потенциальных возможностей усовершенствования Проектирование нового процесса или новой схемы существующего процесса Стимулирование обмена информацией и обсуждений Документальная фиксация требований Процессного управления Главная отправная точка для выработки общего понимания и консенсуса среди заинтересованных сторон Экономия затрат, времени и усилий по сравнению с догадками и экспериментами на действующем процессе Помочь исполнителям увидеть, как входы и выходы их работы влияют на создание ценности сквозным процессом, пересекающим границы подразделений Помочь принимать решения, приводящие не к локальной оптимизации, а к повышению ценности, создаваемой процессом в целом 77 В Таблице 6.2 представлены наиболее распространенные процессные нотации. Таблица 6.2 — Распространенные процессные нотации Нотации Описание BPMN 2.0 Стандарт, созданный консорциумом Object Management Group (OMG); содержит 103 символа; полезен для представления модели разным аудиториям Дорожки Является не самостоятельной нотацией, а дополнением ко многим другим нотация; помогает изобразить переходы ответственности в ходе процесса Блок-схемы Исходно принятый в качестве стандарта ANSI, включает небольшой и очень простой набор символов; позволяет быстро ухватить ход потока работ EPC Нотация, разработанная в рамках методологии ARIS, рассматривает входы и выходы шагов процесса как события; позволяет моделировать сложные комплексы процессов UML Поддерживаемое OMG семейство нотаций и методов моделирования, предназначенное в основном для описания требований к информационным системам IDEF Стандарт правительства США, акцентирующий внимание на входах, выходах, механизмах и средствах управления процессов и явно увязывающий процесс с выше- и нижестоящими в иерархии детализации; хорошая отправная точка для составления взгляда на организацию как единое целое Карты потоков создания ценности Часть методологии бережливого производства, использует очень простой набор символов; применяется для изображения элементов затрат ресурсов и времени для наглядного анализа эффективности процесса На Рисунках 6.2-6.8 представлены примеры процессов в различных нотациях. [3] Рисунок 6.2 — Простая диаграмма BPMN 78 Рисунок 6.3 — Традиционная диаграмма с дорожками Рисунок 6.4 — Процесс, описанный через блок-схему 79 Рисунок 6.5 — Диаграмма EPC 80 Рисунок 6.6 — Диаграмма UML Рисунок 6.7 — Диаграмма IDEF 81 Рисунок 6.8 — Диаграмма потока создания ценности Моделирование процессов должно охватывать все уровни организации (предприятия). Кроме того, процессы могут моделироваться под разными углами зрения в соответствии с потребностями организации (Рисунок 6.9). Традиционно моделирование процессов используется для: • стратегического планирования; • усовершенствования операций; • составления требований к данным и информационным системам. В свою очередь, анализ процессов необходим для оценки того, насколько эффективно бизнес (предприятие, организация, учреждение) достигает своих целей. Он дает организации информацию, необходимую для оценки выполняемых действий и для принятия обоснованных решений. Основной результат анализа «как есть» — это разделяемое всеми понимание того, как работа выполняется в настоящее время. Опираясь на фундамент задокументированных и подтвержденных фактов анализа текущего состояния, перепроектирование процесса способно добиться более полного достижения целей бизнеса. 82 Рисунок 6.9 — Пример процессной иерархии Основой целостного взгляда на основные бизнес-процессы является понимание стратегии организации. Стратегические соображения задают контекст, исходя из которого определяются цели процесса и цели работы над процессом. Анализ процессов выходит за рамки краткосрочных тактических задач или списка пожеланий подразделения компании — он нацелен на фундаментальные изменения, которые будут способствовать реализации целей и стратегии организации. Мониторинг эффективности процесса с непрерывным отображением метрик позволяет обнаружить рост стоимости или падение производительности процесса. Анализ позволяет понять и измерить результативность и производительность процесса. Полученная в результате анализа информация включает следующее: 83 • понимание стратегии, целей и задач организации; • бизнес-среда и контекст процесса (ради чего процесс существует); • место анализируемого процесса в рамках более широкого кросс- функционального процесса; • входы и выходы процесса, в том числе внутренние и внешние поставщики и потребители; • роли в процессе подразделений-участников и точки передачи ответственности между подразделениями; • оценки масштабируемости и потребления ресурсов; • бизнес-правила, управляющие процессом; • подходящие для целей мониторинга показатели эффективности процесса; • перечень выявленных возможностей повышения качества или производительности. Данная информация является ценным управленческим ресурсом, так как дает понимание того, как работает бизнес, и позволяет принимать обоснованные решения по адаптации к меняющейся среде. Существуют три основных подхода к проектированию процессов: • моделирование до исполнения; • через пользовательские интерфейсы; • автоматизированное выявление. В любом случае результатом является модель процесса в целом или его фрагмента. Первый и наиболее популярный на текущий момент подход – это предварительное моделирование бизнес-процесса, когда процессные модели создаются до исполнения, а затем, по мере обнаружения новых путей, исключений и шагов, в проект вносятся изменения. Некоторые организации предпочитают реализовать процесс в интерфейсах информационной системы и протестировать его на пользователях. Такой подход привлекателен для тех, кто привык больше полагаться на непосредственные ощущения и предпочитает вместо изучения графических схем, путей и решений увидеть что-то работающее. Прототипирование и эмпирическая обкатка – это отличный способ привнести в модель процесса реализм. Автоматизированное выявление основано на анализе фактического исполнения процесса. Тактика при этом может варьироваться. Это может быть простое наблюдение за работой исполнителей, непрерывно обращающихся к различным пунктам меню существующей информационной 84 системы, с целью создания полной процессной модели. Несколько сложнее наблюдать за работниками умственного труда (штатными сотрудниками и фрилансерами), совместно выполняющими задание, с целью выявления альтернативных путей выполнения фрагментов процесса. Процесс проектирования процессов можно представить как последовательность шагов (Рисунок 6.10). Для рассмотрения последовательности шагов предварительно введем ряд понятий. Процесс — это сочетание всех действий, требуемых для достижения цели, получения результата, продукции или услуги, вне зависимости от того, где они выполняются, и необходимого обеспечения. Действия, показанные в контексте их взаимосвязей, образуют последовательность или поток. Рисунок 6.10 — Проектирование процессов Процессы состоят из групп действий, выполняемых людьми и/или машинами для достижения одной или нескольких целей. Они инициируются определенными событиями и порождают определенный результат (или несколько результатов) в виде завершения процесса или передачи ответственности другому процессу. 85 Поток работ — это набор действий, выполняемых одним бизнес- подразделением, включающий работу в одном или нескольких процессах. Такая работа структурируется исходя из требований производительности. Поток работ изображается в виде потока, связывающего каждое действие с остальными, выполняемыми бизнес-подразделением. Процесс состоит из потока подпроцессов, каждый из которых производит определенную часть конечной продукции или услуги. Поскольку процессы, как правило, являются кросс-функциональными, то есть проходят через несколько подразделений, проектирование процесса должно охватывать как верхний уровень процесса, так и действия, выполняемые бизнес-подразделениями. Так как любое подразделение, скорее всего, будет выполнять однотипную работу для множества процессов, любое изменение в деятельности подразделения будет иметь далеко идущие последствия. Поскольку деятельность подразделения структурируется исходя из требований производительности, а не по подпроцессам или бизнес- функциям, связь между действиями подразделения и процессом или процессами оказывается размытой. Из-за этого сложно оценить влияние изменения на процесс. На этом уровне в центре внимания – производительность, а не процесс. Это уровень потока работ. Осуществляя проектирование процесса, нужно понимать, что представляет собой процесс от начала до конца, какие подразделения вовлечены в его исполнение и какие действия они выполняют (Рисунок 6.11). Иначе, при сосредоточении только на каком-то одном уровне, результатом может стать такая модель процесса, которая нанесет ущерб на других уровнях. Например, работу какого-то подразделения могут счесть ненужной и исключить ее, а это негативно скажется на подразделении, расположенном ниже по потоку работ. Или же могут быть приняты такие изменения на уровне процесса, которые скомпрометируют качество или производительность некоторого подразделения. Если же наличествует понимание и процесса, и того, как его действия сочетаются с действиями, выполняемыми данным подразделением в рамках других процессов, то это позволит дать оценку новой модели на всех уровнях и убедиться, что от усовершенствования выиграют все. Проектирование процесса включает в себя описание и упорядочивание составляющих процесс функций и действий, а также вспомогательных средств, технологий производства и информационных систем. Результатом являются спецификации нового или модифицированного бизнес-процесса. 86 Рисунок 6.11 — Структура «процесс – подразделение – поток работ» Также проектирование процесса включает изучение существующего процесса и его подпроцессов и анализ того, как он может быть усовершенствован или фундаментально пересмотрен для достижения желаемого результата. Модель нового процесса должна рассматривать действия вне зависимости от того, какие подразделений их выполняют — это следствие кросс-функциональной природы процесса. Рассмотрение верхнего уровня процесса продолжается на уровне подпроцесса, где работа распределяется по бизнес-функциям и подразделениям. На уровне подразделения действия, относящиеся к данному процессу, объединяются с действиями в рамках других процессов, образуя поток работ. Проектирование процесса начинается с изучения того, как бизнес работает сегодня — что он делает, где, как и зачем. Это исследование документированных и недокументированных действий, составляющих процесс. Но важно понимать не только как бизнес работает, но и как он должен работать, по мнению высшего руководства. Что делается не так и почему? Где возникают проблемы при передаче ответственности между подразделениями, при принятии решений? Где бизнес-правила не задокументированы и допускают вольную трактовку? Изучение документации позволяет сформулировать перечень вопросов для последующих интервью и рабочих совещаний с руководителями и персоналом. Сбор информации необходимо стандартизовать, т.е. определить, какую информацию от кого следует требовать, как ее проверять, организовывать и хранить, порядок ее использования и обновления. 87 Обследование процесса дает информацию, относящуюся к разным уровням детализации модели процесса. Эти уровни следует упорядочить и в дальнейшем привязывать к ним собираемую информацию. Верхний уровень иерархии составляет процесс в целом, который затем декомпозируется на уровни ниже, вплоть до отдельных действий. В ходе декомпозиции процесс разбивается на подпроцессы и затем на функции. Функции привязываются к подразделениям. Действия, выполняемые в рамках подразделения, вместе с действиями, относящимися к другим подпроцессам, образуют поток работ. В ходе обследования процесса рекомендуется привязывать собираемую информацию к определенному уровню детализации. Со временем эта привязка может меняться. Информация на любом уровне должна четко соответствовать информации на вышележащем уровне, представляя собой ее детализацию. Процессная иерархия как пример представлена на Рисунке 6.12. Различные организации могут использовать больше или меньше уровней и называть их иначе. В тоже время качественный стандарт моделирования должен содержать в том или ином виде, по крайней мере, следующие уровни. Верхний уровень — это модель сквозного процесса. Она может содержать подпроцессы, а также отображать информационные системы и проблемы верхнего уровня. Следующий уровень — это модели подпроцессов, показывающие распределение работы по бизнес-функциям и соответствие между бизнес- функциями и подразделениями. Третий уровень — это поток работ внутри подразделения, показывающий выполняющиеся действия. Модели этого уровня могут также показывать связь между действиями, выполняемыми в этом же подразделении в рамках других функций и подпроцессов. Четвертый уровень детализации — сценарии, он позволяет понять, какими событиями, таймерами или данными вызываются выполняемые в подразделении работы. Сворачивая задачи в действия, а те, в свою очередь, в потоки работ и подпроцессы, можно легко проследить, как работа складывается в процесс, и ее роль в создании конечной продукции процесса. Но и четвертый уровень обеспечивает только базовое понимание бизнес-операций. Этого уровня детализации зачастую недостаточно для решения проблем, сокращения затрат или автоматизации. Для этого может понадобиться детализировать поток работ до уровня задач. 88 Рисунок 6.12 — Уровни детализации при моделировании процессов На пятом уровне определяются задачи, выполнение которых дает требуемый выход или результат действия. Например, если речь идет о вводе нового страхового полиса в систему страховой компании, на этом уровне определяется задача, которая должна быть выполнена, чтобы ввести новый полис. Другой пример, относящийся к этому уровню, из области производства на заказ: действия после того, как продавец получил заказ от клиента. Нужно расписать все задачи, которые должны быть выполнены для спецификации заказной продукции, для идентификации узлов (в предположении, что продукция изготавливается из стандартных компонент), для задания опций, для формирования заказов на поставку узлов и сборку. Возможно, понадобятся и еще более низкие уровни детализации. Главное, довести схему до уровня, обеспечивающего ясное понимание того, что делает конкретный сотрудник, и того, что будет делаться на следующей стадии. Описывая процессы «как есть», аналитики получают возможность собрать следующую информацию: 1. Для процессов – подпроцессы и их взаимодействие. 89 2. Для подпроцессов – бизнес-функции/сценарии и подразделения, которые их выполняют. 3. Для потоков работ в рамках бизнес-подразделения – выполняемые действия (может детализироваться на более низкие уровни, чтобы показать задачи, из которых состоит действие). 4. Проблемы и их последствия в привязке к одному или нескольким подпроцессам, бизнес-функциям, действиям или задачам, на которых они сказываются. 5. Возможности для усовершенствования и ожидаемый эффект в привязке к части бизнеса, к которой они относятся. 6. Метрики (численность сотрудников, объем выполняемой работы, частота ошибок), привязанные к точке операции, в которой они измеряются. 7. Используемые IТ-приложения и где они используются. 8. Основная функциональность каждого IТ-приложения. 9. Данные – где хранятся, как вводятся и как используются. 10. Правила – писаные и неписаные. 11. Процедуры принятия решений с вероятностями исходов. 12. Нормативы качества/продолжительности/производительности и т. п. 13. Политика внутреннего аудита и прочие требования. 14. Требования к измерению эффективности. В процессе описания процессов «как есть» рекомендуется обращать внимание на результаты деятельности подразделений, бизнес-функций и подпроцессов. Вся выполняемая работа должна вносить вклад в достижение одного или нескольких результатов, в противном случае следует проанализировать ее целесообразность. Необходимо также четко идентифицировать и описать все имеющиеся проблемы. Они должны быть привязаны к действиям и бизнес-функциям, на которые они влияют. Степень влияния следует оценить и дать результаты оценки на утверждение руководителю. Результаты анализа можно наглядно отобразить в виде матрицы проблем (Рисунок 6.13). Даная матрица показывает проблемы и подразделения/действия, на которые они влияют, а на пересечении тех и других – само влияние. В ходе проектирования такое представление неоднократно окажется полезным. 90 Рисунок 6.13 — Матрица проблем Помимо проблем, в ходе обследования выявляются возможности совершенствования в привязке к потенциальному эффекту от их реализации. Эти зависимости отображаются через матрицу возможностей (Рисунок 6.14), в которой по одной оси отображается возможность, по другой — подразделение/действие, а на пересечении — эффект от изменения для бизнеса. Рисунок 6.14 — Матрица возможностей В процессе реализации этапов по проектированию процессов нужно обращать внимание на управление потоками работ и на возможности 91 улучшения таких аспектов, как списки задач, мониторинг потоков работ, контроль на соответствие стандартам, предупреждения о превышении нормативов времени, автоматическое назначение задач и перераспределение задач с целью балансировки нагрузки сотрудников. Параллельно с проведением анализа рассмотренных выше аспектов также важно обращать внимание на информационные технологии. Нужно выяснить, где возможности информационных технологий в части поддержки существующих и вероятных будущих бизнес-операций являются недостаточными. Установленные таким образом факты могут ограничить диапазон возможных будущих бизнес-моделей. В ходе анализа всегда обращаются к двум ключевым вопросам. Первый — как выполнить работу более производительно и с меньшими затратами? Второй — как сделать бизнес-операции более гибкими и способными к быстрым изменениям? Это сочетание обеспечит долговременную оптимизацию через постоянное совершенствование. В дальнейшем приступают к перепроектированию (проектированию) процессов (Рисунок 6.15). Приступая к перепроектированию, важно смотреть на схему «как есть» как на модульную. Каждое действие выполняется независимо, но оно связано с другими действиями входами и выходами. Выполняемая в нем работа контролируется руководителем и бизнес-правилами. IТ обеспечивает работу, предоставляя информационные системы и данные. Поток работ при таком подходе можно рассматривать как модуль, состоящий из более мелких модулей. Основная идея заключается в том, что любой модуль на любом уровне представляет собой полнофункциональный элемент бизнеса. Он производит нечто, потребляемое другими модулями. Модули являются кирпичиками, которые комбинируются в последовательности, производящие продукцию или услугу более высокого уровня. Все модули взаимозаменяемы и допускают повторное использование. Такая модульность обеспечивается определенным подходом к работе. Целостность модуля обеспечивается неизменностью его входов и выходов (только качество результата может улучшаться). Проектировщики могут менять модуль как угодно при условии, что его входы и выходы остаются неизменными. Если же выходы меняются, то воздействие такого изменения распространяется дальше по потоку, и возникает необходимость рассматривать как очевидные, так и скрытые последствия. 92 Рисунок 6.15 — Действия по проектированию процессов При проектировании выполняются последовательно или параллельно- последовательно следующие ключевые действия: 1. Проектирование нового процесса на соответствующую глубину детализации (согласно процессной иерархии). 2. Выявление действий в рамках нового процесса, описание потока работ и зависимостей. 3. Описание сценариев процессной работы и выделение модулей на основе этих сценариев. 4. Описание потребностей в данных. 5. Описание бизнес-правил. 6. Описание передачи ответственности за процесс между функциональными группами. 7. Определение показателей успешности изменения и эффекта с точки зрения потребителя. 8. Определение целевых уровней показателей нового процесса. 93 9. Определение и проектирование бизнес-отчетности и отчетности по эффективности. 10. Оценка величины разрыва между текущим и желаемым положением дел. 11. Разработка требований и спецификаций изменения бизнеса и информационных систем. 12. Проектирование на физическом уровне. 13. Анализ и проектирование IТ-инфраструктуры. 14. Имитационное моделирование, тестирование и приемка. 15. Автоматическая генерация или разработка IТ-приложений. 16. Проектирование и разработка интерфейсов к унаследованным приложениям и данным. 17. Комплексное тестирование, включающее использование новых и унаследованных приложений и правил. 18. Разработка и реализация плана внедрения. Рисунок 6.16 отражает место проектирования процессов. Рисунок 6.15 — Место проектирования процессов При этом само перепроектирование существующего процесса основано на идее пересмотра статус-кво и необходимости усовершенствования процесса. Это касается всех уровней процессной иерархии. Ни одна часть 94 процесса не принимается как должное, каждая изучается на предмет возможности сократить трудозатраты, повысить качество, снизить стоимость и устранить проблемы. Команда возвращается к проблемам, обнаруженным в ходе обследования, чтобы выявить изменения в работе, в принятии решений, в передаче ответственности, которые вызвали их возникновение, и избавиться от проблем путем исключения из новой модели их первопричин. Вопросы качества, численности персонала, обучения и т. п. тоже должны быть учтены в новой модели, но первейшая задача – устранение проблем. Критически важно привлечь к рассмотрению нового проекта как можно больше непосредственных участников процесса из разных функциональных областей, чтобы воспользоваться их обширным опытом и знаниями. Это дает уверенность в том, что процесс не расходится с возможностями организации, а также позволит рассеять страх и вовлечь людей, сделав их сторонниками изменений. 1. В чем цель этого процесса, подпроцесса, потока работ или действия? 2. Не является ли он избыточными или похожим на уже имеющийся? 3. Какие здесь есть проблемы, какие возникают вопросы к качеству и к контролю и почему они возникают? 4. Почему необходим этот шаг? 5. Какова его цель? 6. Где он должен выполняться? 7. Когда он должен выполняться? 8. Кто лучше всех подходит для его выполнения? 9. Адекватен ли уровень автоматизации? 10. В чем основные проблемы? 11. Как их можно устранить? 12. Как сделать процесс максимально результативным (делать только то, что нужно)? 13. Как сделать процесс максимально производительным (устранить лишние действия)? 14. Как можно устранить выявленные лишние действия? 15. Каким стандартам необходимо соответствовать? 16. Как осуществляется мониторинг и контролируется достижение целевых показателей эффективности? 17. Какие факторы ограничивают возможности изменения процесса, подпроцесса, потока работ, действия или сценария? 95 В дальнейшем новая модель бизнес-операций может потребовать изменений в IТ-приложениях и поменять то, как операции распределяются по офису и по производственным помещениям компании. Это, в свою очередь, повлияет на требования к IТ-инфраструктуре и коммуникациям. Новая модель может также вызвать изменение требований к интерфейсам унаследованных приложений и к интерфейсам доступа к данным, которые, в свою очередь, могут повлиять на IТ-стратегию и инфраструктуру, включая хранение и использование данных и документов. Если выбран путь эволюционных изменений, то требуется проанализировать IТ-инфраструктуру и привязать ее изменения к фазам эволюции бизнес-операций. Это позволит учесть планируемые изменения бизнеса в планах и бюджете IТ-отдела. Это также даст возможность группе архитектуры предприятия в составе IТ заранее начать присматриваться к новым технологиям и к новым приложениям, чтобы в момент, предусмотренный планом эволюционных изменений, выбрать оптимальное решение. Ниже представлены вопросы, которые встанут перед IТ. 1. Какое программное обеспечение максимально соответствует требованиям процесса? 2. Накладывает ли текущая инфраструктура ограничения на возможную модель бизнеса? 3. Возможно ли быстро внедрить новую модель бизнеса? 4. Как изменения в IТ влияют на организацию? 5. Можно ли прибегнуть к поэтапному подходу? 6. Каковы затраты на внедрение новой модели (включая обучение, программное обеспечение и т. д.)? 7. Могут ли поставщики программного обеспечения помочь с внедрением? Таким образом, проектирование процессов является неотъемлемой частью используемых, внедряемых, модернизируемых информационных систем и технологий предприятий и организаций, и того как систематично и качественно будут подходить к решению данного вопроса руководители организаций будет зависеть эффективность применения ИТ и успешность организации. |