Проектирование модели бизнес-процессов. Бизнес процесс проектирования


Проектирование модели бизнес-процессов | Открытые системы. СУБД

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

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

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

Текущее состояние

Часто сквозные процессы делят на модули, исполняемые целиком внутри организационных единиц компании, — их называют бизнес-процессами подразделения [1]. Такой способ локализации бизнес-процесса в рамках одного структурного подразделения свойственен функциональному подходу к управлению организацией и может противоречить основной цели моделирования — переходу к процессному управлению. Рекомендуется выявлять процессы с помощью цепочек создания ценностей [2]. Для этого предлагается: выявить клиентов компании; определить, какие продукты потребляют эти клиенты; определить поток преобразования продуктов или услуг, итогом которого является результат, ценный для клиента компании. Если компания выпускает материальный продукт, то определение цепочки создания ценности является относительно простой задачей, однако если компания предоставляет  услугу, то обнаружение цепочки ее создания существенно сложнее.

Чтобы сделать схему процесса читаемой и понятной, предлагается создавать иерархическую модель, где верхний уровень дает самое общее представление о ходе исполнения процесса, а все детали исполнения «спрятаны» на нижних уровнях [3]. Идея правильная, однако непонятно, как построить иерархию процесса, раскрывая его снизу вверх.

В качестве критерия разделения сквозного процесса на цепочку взаимодействующих подпроцессов ряд авторов советуют анализировать выходы одного этапа процесса и входы следующего [4]. Действительно, если вход и выход соотносятся как 1:1, то процесс можно рассматривать как монолитный, но если соотношение имеет вид 1:М или М:1, то это свидетельствует о разделении процесса на подпроцессы.

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

Объект управления

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

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

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

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

Декомпозиция процесса

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

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

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

Примеры деления на подпроцессы

Рассмотрим типичный пример процесса заключения договора в нотации BPMN [6]. В примере имеются две точки старта, причем одна из них ведет в середину процесса, и несколько завершающих событий, некоторые из которых находятся в середине процесса (рис. 1). Сквозной процесс имеет два объекта управления: коммерческое предложение и договор — внимательный аналитик увидит смену объекта управления и предположит, что сквозной процесс распадется на два подпроцесса: «Согласовать коммерческое предложение» и «Заключить договор».

 

Рис. 1. Сквозной процесс от заявки до договора

 

В качестве второго примера, иллюстрирующего предлагаемый подход, рассмотрим бизнес-процесс присуждения Нобелевской премии, взятый из альбома типовых моделей в нотации BPMN [7]. В этом процессе можно выделить следующие объекты управления:

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

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

Этапы исполнения процесса

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

Декомпозиция процесса по этапам жизненного цикла объекта управления позволяет расположить этапы исполнения в естественном порядке следования. Они связаны безусловными переходами и образуют основной сценарий исполнения процесса [8], который не предполагает показывать альтернативные маршруты и варианты ветвления. Поэтому следующим шагом нужно уточнить модель: расширить — добавить в основной сценарий пропущенные варианты исполнения и углубить — детализовать каждый из подпроцессов. Можно оформить каждый этап как подпроцесс в нотации BPMN, тогда основной сценарий будет изображаться цепочкой подпроцессов, связанных безусловными переходами (рис. 2). Например, объект управления «Заказ» имеет следующие этапы жизненного цикла: оформление, проверка реализуемости, согласование условий, исполнение, передача заказчику и завершение финансовых расчетов. Затем основной сценарий следует уточнить: (а) расширить — добавить пропущенные варианты исполнения, (б) углубить — детализовать каждый из подпроцессов.

 

Рис. 2. Основной сценарий исполнения процесса

 

Моделирование организационных обязанностей

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

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

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

 

Псевдороли при организационном взаимодействии   Псевдороль Функция
1. Распределяющий Оценка задания, установка приоритетов и сроков
2. Диспетчеризация, отбор и назначение исполнителя в соответствии с критериями
3. Возложение поручения на выбранного  исполнителя 
4. Исполнитель Выполнение функционального поручения
5. Информируемый Координация работы
6. Проверяющий Проверка качества выполненных работ
7. Визирующий Утверждение результата своей подписью
8. Передача задания на следующий этап обработки

 

Следующий пример (рис. 3) показывает схему взаимодействия сотрудников одного подразделения. Обычно руководитель подразделения играет сразу несколько ролей: «Распределяющий», «Информируемый», «Проверяющий», «Визирующий». Если руководитель хочет иметь возможность самостоятельно исполнять задание, он должен быть приписан к роли «Исполнитель».

 

Рис. 3. Организационное взаимодействие участников

 

***

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

Литература

  1. Репин В. В., Елиферов В. Г. Процессный подход к управлению. Моделирование бизнес-процессов. — М.: Манн, Иванов и Фербер, 2012.
  2. Сооляттэ А.Ю., Репин В. В. Цепочка создания ценности — основа для построения сети бизнес-процессов компании // Финэксперт.
  3. Silver B., BPMN Method and Syle, 2009.
  4. Sharp А., McDermott P., Workflow Modeling. Artech House Publishers, 2001.
  5. Mendling J., Neumann G., Van der Aalst W., Understanding the Occurrence of Errors in Process Models Based on Metrics // In: Proceedings of the OTM Conference on Cooperative information Systems (CoopIS 2007). Berlin: Springer-Verlag, 2007.
  6. Белайчук А. Процессный паттерн: Cнова здравствуйте! [Электронный ресурс]. URL: mainthing.ru/ru/item/537/#more-537. 2012. (Из BPM-блога «Главное не результат, главное процесс»). 
  7. OMG. BPMN 2.0 by Example. OMG Document Number: dtc/2010-06-02. www.omg.org/spec/BPMN/2.0/examples/PDF
  8. Федоров И.Г. Системный подход к выявлению бизнес-процессов методом «сверху вниз» // Прикладная информатика. — 2012. No. 5 (41), — C.5–13.

Игорь Федоров ([email protected]) — профессор, Московский государственный университет экономики, статистики и информатики (Москва).

www.osp.ru

С чего начать разработку бизнес процессов / Хабр

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

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

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

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

Итак, в общем случае задание было следующим: 1. Напишите, какие ресурсы требуются для приготовления яичницы. 2. Какие «технические» операции необходимо совершить, чтобы на столе стояла «Скворчащая, годная к употреблению яичница». Ниже привожу сверочный список, кому интересно, составьте свой и сравните. В ресурсах и технических операциях сознательно пропущено несколько пунктов, буду рад, если заметите.

Ресурсы: 1. Два яйца. 2. Столовая ложка подсолнечного масла. 3. Плита. 4. Газ. 5. Соль. 6. Вилка. 7. Столовая ложка. 8. Тарелка для второго блюда. 9. Мусорное ведро. Технические операции: 1. Зажечь газ. 2. Поставить сковороду на зажженную конфорку и через минуту убавить газ до минимума. 3. Налить подсолнечное масло в столовую ложку и добавить его в сковородку. 4. Распределить масло по всей поверхности сковородки. 5. Достать из холодильника два яйца. 6. Взять нож из кухонного гарнитура. 7. Взять первое яйцо в левую руку, а нож в правую. 8. Ударить тыльной стороной ножа по скорлупе так, чтобы появилась трещина на скорлупе. 9. Положить нож. 10. Разъединить половинки скорлупы над сковородкой на расстоянии примерно 5 – 10 сантиметров над поверхностью. 11. Повторить шаги с 7 по 10 со вторым яйцом. 12. Двумя пальцами правой руки взять «щепотку» соли и посолить яичницу. 13. Выждать семь минут. 14. Выключить газ. 15. Поставить на стол тарелку для второго блюда. 16. Взять сковородку в правую руку. 17. Аккуратно вилкой выложить содержимое на тарелку для второго блюда. 18. Сковородку поставить в мойку. 19. Тарелку с яичницей поставить на стол. 20. Достать из кухонного гарнитура вилку и положить рядом с тарелкой. 21. Скорлупу положить в ведро для мусора. 22. Нож положить в мойку.

После этой несложной на первой взгляд процедуры, сотрудники компаний в буквальном смысле расцветали на глазах, приговаривая «Ах вон оно, что от нас требуется»!

habr.com

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

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

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

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

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

В этом разделе мы рассмотрим проектирование бизнес-процессов через создание и изменение элементов специального справочника «Виды бизнес-процессов». Виды бизнес-процессов располагаются в подсистеме «Корпоративные процессы» системы документооборота СЭД «Корпоративный документооборот».

Каждый вид бизнес-процесса представляет собой отдельный набор следующих объектов системы:

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

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

2. Список исполнителей заданий бизнес-процессов. Список исполнителей может быть определен как для всего бизнес-процесса в целом, так и для каждой его точки действия. Список исполнителей может включать в себя как конкретных исполнителей (сотрудников предприятия), так и точки ролевой адресации. В точках ролевой адресации используются не конкретные сотрудники предприятия, а роли и объекты адресации, например «Руководитель проекта №1», «Руководитель отдела АСУ» и другие. Список исполнителей может быть быстро определен с использованием рабочих групп, сформированных в справочнике «Рабочие группы». В рабочие группы могут включаться как сотрудники, так и точки ролевой адресации.

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

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

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

Кроме вышеописанных объектов, каждый вид бизнес-процесса включает в себя ряд других, вспомогательных объектов СЭД «Корпоративный документооборот».

Обмен видами процессов

Виды бизнес-процессов могут быть сохранены в файл формата bpl. Данный файл содержит xml-описание вида процесса, а также xml-описание ряда вспомогательных объектов. Файлы формата bpl могут быть свободно сохранены для архивирования устаревших версий или обмена с другими проектировщиками (в системе также реализована загрузка видов процессов из файлов формата bpl). Файлы также могут быть заархивированы в zip-архивы, при этом их распаковка производится автоматически при загрузке файлов в СЭД «Корпоративный документооборот».

Проектирование видов бизнес-процессовПараметры доступа к странице библиотеке бизнес-процессов, размещенных на сайте доступны всем зарегистрированным пользователям СЭД «Корпоративный документооборот». На данный день в библиотеке доступны следующие виды бизнес-процессов:

Корпоративный бизнес-процесс «Согласование документов». Бизнес-процесс предназначен для автоматизации процесса согласования документов предприятия. По результатам согласования корпоративный документ (документы) могут быть автоматически направлены на подпись руководителю.

Корпоративный бизнес-процесс «Бронирование ресурсов». Бизнес-процесс предназначен для демонстрации возможности работы с ресурсами предприятия на примере бронирования конференц-зала для проведения встречи. В бизнес-процессе используется таймер и подпроцесс «Служебная записка».

Корпоративный бизнес-процесс «Совещание». Бизнес-процесс предназначен для утверждения повесток совещаний и проведения совещания сотрудников предприятия.

Корпоративный бизнес-процесс «Служебная записка». Бизнес-процесс предназначен для создания и обработки служебных записок сотрудников.

Корпоративный бизнес-процесс «Ознакомление с документом». Бизнес-процесс предназначен для проведения ознакомления сотрудников с корпоративным документом (документами) и присвоению документам соответствующих статусов.

Корпоративный бизнес-процесс «Закупка оборудования». Бизнес-процесс предназначен для демонстрации возможностей по построению бизнес-процессов с использованием объектов разделения и слияния ветвей процесса, а также точек выбора по нескольким вариантам дальнейшего маршрута.

Корпоративный бизнес-процесс «Поручение сотрудникам». Бизнес-процесс предназначен для выдачи поручений и контроля их исполнения.

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

Пользователи СЭД «Корпоративный документооборот» могут создать заранее включенные в поставку виды процессов, для этого необходимо открыть пункт меню «Библиотека Типовые процессы» в форме списка видов процесса. Загрузка новых видов процессов может производиться только в режиме толстого клиента.

Проектирование вида процесса

Для проектирования бизнес-процесса необходимо настроить его вид в справочнике «Виды бизнес-процессов».

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

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

При проектировании маршрута необходимо:

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

Определить параметры каждой маршрутной точки. Набор параметров маршрутной точки определяется её типом. Подробнее о маршрутных точках смотрите в разделе «Маршрутные точки корпоративных процессов«.

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

 

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

На закладке «Схема бизнес-процесса» можно указать произвольное описание вида бизнес-процесса для других пользователей. Для открытия описания нажмите на гиперссылку «Показать описание процесса».

Параметры бизнес-процесса

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

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

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

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

Список основных исполнителей

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

Список основных исполнителей может быть составлен из сотрудников предприятия и с использованием ролевой адресации. При ролевой адресации необходимо указать роль исполнителя и, при необходимости, объекты адресации.

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

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

Реквизиты процесса

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

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

Настройка элементов форм

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

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

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

Прочие настройки и параметры

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

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

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

Видео-ролик «Бизнес-процессы и задачи в СЭД «Корпоративный документооборот»

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

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

Начать просмотр

Смотрите также:

xn--90afdtkhdeabaxvge.net

Разработка бизнес-процессов (описание, моделирование, реинжиниринг) от Систус Консалт

 

 

Разработка и реинжиниринг бизнес-процессов

 

 

 

 

ВНИМАНИЕ!

Приглашаем пройти обучение с одновременным консультированием по разработке и внедрению СМК по стандарту ISO 9001:2015 (ГОСТ Р ИСО 9001-2015) , кому предстоит самостоятельно разрабатывать СМК. Подробнее читать...

 

 

Разработка, моделирование, описание, реинжиниринг бизнес-процессов. Какова  актуальность?

В работе каждого генерального директора постоянно возникает вопрос: Что надо изменить в компании, чтобы повысить исполнительность сотрудников и производительность их труда, снизить непроизводственные потери, увеличить количество заказчиков и объем заказов, одним словом - как повысить эффективность и прибыльность организации?

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

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

К тому же оптимизация бизнес-процессов, как показывает практика, является самым дешевым и самым эффективным способом улучшения работы компании.

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

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

 

 

 

 

 

Моделирование бизнес-процессов, разработка бизнес-процессов – ключевой элемент СМК

Процессное управление и система бизнес-процессов является ключевым элементом систем менеджмента качества (СМК) по ISO 9001 (ИСО 9001), при чем разработка и внедрение СМК является главным направлением нашей деятельности. Таким образом, создав систему управления бизнес-процессами, Вы во многом подготовите компанию к разработке и внедрению СМК.

 

ВНИМАНИЕ! В случае разработки (моделирования) системы бизнес-процессов снижается стоимость услуги «Разработка системы менеджмента качества (СМК) по ISO 9001» .

 

 

Разработанная нами система управления бизнес-процессами легко встраивается в любую автоматизированную информационную систему управления производственной деятельностью компании (автоматизация бизнес-процессов).

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

 

Разработка бизнес-процессов (моделирование, описание, реинжиниринг бизнес-процессов) включает комплекс работ

Перечень работ

  1. Обследование существующей системы управления компанией.
  2. Разработка модели (сети) бизнес-процессов (описание, моделирование бизнес-процессов).
  3. Разработка показателей и методов мониторинга бизнес-процессов.
  4. Разработка системы показателей эффективности и результативности бизнес-процессов.
  5. Разработка стандартов, регламентов или карт бизнес-процессов (описание бизнес-процессов по функциям, разработка блок-схем бизнес-процессов) с применением риск-менеджмента.
  6. Разработка схемы последовательности и взаимодействия бизнес-процессов.
  7. Доработка схемы организационной структуры компании, положений о подразделениях, должностных и профессиональных инструкций.

 

Описание бизнес-процессов (оптимизация бизнес-процессов) включает следующий состав работ

  1. Обследование существующей системы управления компанией. Разработка системы бизнес-процессов начинается со сбора и анализа информации о действующих бизнес-процессах; о недостатках, имеющихся при осуществлении работы подразделений и отдельных должностных лиц; об элементах системы управления, требующих оптимизации (реинжиниринга) бизнес-процессов; о корпоративной культуре в компании; изучается внешняя и внутренняя нормативная документация компании, др.
  2. Разработка модели (сети) бизнес-процессов. На этом этапе фактически начинается разработка (моделирование) системы управления бизнес-процессами. Определяются бизнес-процессы, их взаимосвязь между собою. Назначаются владельцы бизнес-процессов. Строится графическая сеть или модель бизнес-процессов.
  3. Разработка показателей и методов мониторинга бизнес-процессов. Определяются ключевые параметры (реперные точки) бизнес-процессов, выполняя которые владельцы бизнес-процессов обеспечивают нормальный ход бизнес-процесса. Выбираются наиболее действенные методы мониторинга бизнес-процессов.
  4. Разработка системы показателей эффективности бизнес-процессов. Разработка показателей для оценки функционирования каждого бизнес-процесса. Создание механизма определения планируемых показателей бизнес-процессов и оценки их результатов.
  5. Процедура «Разработка стандартов, регламентов или карт бизнес-процессов» включает в себя работы по созданию документов, в которых приведено описание бизнес-процессов по функциям, блок-схем бизнес-процессов СМК, процедур и ресурсов бизнес-процессов. Другими словами, осуществляется моделирование бизнес-процессов. На данном этапе работ проводится реинжиниринг (оптимизация) бизнес-процессов с учетом их взаимодействия. В процессы СМК встраивается система управления рисками, что обеспечивает повышение эффективности и результативности СМК.
  6. Разработка схемы последовательности и взаимодействия  бизнес-процессов. Документируется взаимодействие бизнес-процессов по входным и выходным данным с целью визуализации системы бизнес-процессов. Определяется и документируется очередность выполнения бизнес-процессов с учетом их взаимосвязи.
  7. Доработка схемы организационной структуры компании, положений о подразделениях, должностных и профессиональных инструкций. На этом этапе проекта вносятся изменения в организационно-распорядительные документы компании по результатам услуги «Описание бизнес-процессов, реинжиниринг бизнес-процессов». Обязанности, функции, права и ответственность, изложенные в положениях о подразделениях, должностных и профессиональных инструкциях корректируются с учетом разработанных бизнес-процессов или бизнес-процессов, прошедших процедуру – реинжиниринг (оптимизация) бизнес-процессов.

 

Стоимость (цена) и продолжительность работ

Стоимость и продолжительность услуги "Разработка (моделирование) бизнес-процессов, реинжиниринг (оптимизация) бизнес процессов" определяется для каждой организации индивидуально, исходя из таких основных факторов, как:

  • численность персонала организации;
  • месторасположение организации;
  • месторасположение филиалов и/или обособленных подразделений и численность персонала в них;
  • виды деятельности и сложность процессов.

 

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

 

 

ВНИМАНИЕ! Услуга «Описание (моделирование) бизнес-процессов, реинжиниринг бизнес-процессов» оказывается с учетом всех требований ISO 9001 (ИСО 9001), предъявляемых к системам менеджмента качества (СМК). Разработанная система управаления бизнес-процессами создает основу системы менеджмента качества компании и её наличие почти в 2 раза сокращает затраты на разработку СМК.

 

 

Более подробную информацию об услугах, включая стоимость и продолжительность работ, можно получить по телефону: +7 (915) 281-03-08 или по электронной почте: [email protected]

www.sistus-iso.ru

Бизнес-процесс менеджмент. Часть 3 - Проектирование процессов..

Продолжаю описание Системы управления бизнес-процессами ПАРД.Для того что бы процесс начал работать именно так как нужно, и наиболее оптимальным способом, для достижения результатов его нужно спроектировать или по другому запрограммировать.В моей системе для этого есть несложный алгоритм из 6 шагов. Я его постоянно совершенствую. Еще недавно, в своем посте я описывал 10 шагов.

Для описания процессов я использую различные инструменты, которые тут и привожу.

Используемый язык: 

Программы, которые использую я: 

- www.gliffy.com - онлайн-сервис, который позволяет рисовать любые диаграммы в том числе содержит обозначения BPMN.

- GoogleDoks - можно рисовать, но только в простых обозначениях. Удобно расшаривать, сохранять как рисунок и вставлять в корп-портал. Не удобно из-за примитивного "инструментария".

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

- CRM-Mawisoft. Очень удобно отслеживать некоторые процессы. Например: Выполнение заказа, Обработка претензии. Существует специализированный софт, который позволяет отслеживать процессы, но он нужен предприятиям на которых как минимум есть отдельный процес-менеджер или даже отдел.

- OmniGraffe - Великолепная программа для рисования диаграм на IPad. Практически полностью удовлетворяет потребности в функционале и позволяет работать над процессами в дороге или в кафе. Маст Хев(как грится).

Алгоритм проектирования процесса(для новых процессов):

1. Определить цель процесса.

-Определяем событие старта прцесса.

-Определяем конечный продукт(результат) процесса.-Определяем событие завершения процесса.

2. Составить перечень задач, которые по первоначальному мнению, необходимы для выполнения процесса.

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

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

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

3. Выстроить задачи в цепочку последовательно.Выстраивать так как будто все задачи процесса будет выполнять один человек.

4. Распределить задачи между сотрудниками в соответствии с компетенциями.

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

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

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

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

5. Сведение задач из последовательной цепочки в параллельные цепочки субьектов.

- Выявить возможность выполнения задач параллельно разными сотрудниками. 

6. Привязать(по возможности) выполнение задач ко времени, это будет первым шагом к регламентированию работы ваших сотрудников. 

Рассмотрим все написанное на конкретном примере:

Мы хотим спроектировать процесс обработки претензий. Так и назовем - Обработка претензий. Я буду рассматривать на примере компании, которая продает запчати для грузовых автомобилей. Оптом по России, корпоративным клиентам.(Есть у меня такой проект в планах)

У нас есть Конечный Внутренний Продукт (КВП) -Лояльный клиент, одним из составляющих этого Продукта мы выявили подпродукт - Решенные претензии клиента, снятый негатив от претензии.

И вот мы решили спроектировать бизнес-процесс для создания этого КВП. Тут по пути появился Отдел Лояльности, который отвечает за этот КВП.

1. Определяем цель процесса:

Цель процесса: Решенная претензия клиента, снятый негатив от претензии. 

Событие старта процесса: Клиент обратился с претензией

Результат процесса: Решенная претензия клиента

Конечное событие процесса: Следующий заказ клиента.

2. Составляем перечень задачь:

- регистрация претензии

- рассмотрение справедливости претензии 

- выявление причины возникновения  брака в работе или детали

- устранение ошибки в процессах, которая привела к возникновению брака

- замена бракованного товара

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

Мы накидали перечень задач "на вскидку" , пока нам кажется что этогодостаточно, мы еще не рассмотрели вариативность на некоторых этапах ине выявили подпроцессы. Для начала проектирования этого вполнедостаточно.

3. Начинаем выстраивать задачи в цепочку:

РИС.1

ОБП_Обработка_претензий_(Запчасти_авто)Версия1Вот что у нас получилось. Во первых - у нас появились дополнительныезадачи, которые мы первоначально не смогли предусмотреть.

Во вторых - у нас появилась вариативность в некоторых местах.

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

Выстраиваем и добавляем задачи исходя из идеологии компании и здравого смысла. Что значит исходя из идиологии? Это значит, что действуем в соответствии с ценностями компании и целями.

Например: У меня есть ценность - открытость. В соответствии с этой ценностью я выставил задачи: Связаться с клиентом и сообщить о устранении ошибки.,Связаться с клиентом

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

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

4.  Распределяем задачи между подразделениями или сотрудниками:

РИС.2

Вот что получилось в результате.

Дальше:

-Определить количество времени необходимого для выполнения каждойзадачи один раз.

В данном случае не нужно считать время всех задач. Не стоит считатьсколько времени потребуется на звоки клиенту. А вот посчитать примерновремя подпроцессов нужно обязательно.

- Выявить перегруженность или недозагруженность того или иного участника процесса. УСтранить выявленные дисбалансы.

Тут, даже на вскидку, видно что задачи распределены равномерно. Перезагруженность того или иного участника процессов можно выявить только заглянув в Карту процессов и Регламент сотрудника и увидет степень загруженности специалиста.

5. Сведение задачь из последовательной цепочки в параллельные цепочки субьектов:

- Выявить возможность выполнения задачь параллельно разными сотрудниками. 

В нашеп процессе не так то и много задачь, которые можно делать параллельно.

Но во время это работы, у меня процесс разбился на два самостоятельных. 

РИС.3

Так же, я разделил весь процесс на этапы. Это важно будет на этапе работы процессов. Если вы используете прграмму для отслеждивания работы процесса, тоо вы сможете видеть на каком этапе находиться процесс.

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

6.Привязать выполнение задач ко времению:

Нужна подумать и решить, какие задачи мы можем привязать ко времени. Например обработка претензий в нашем случае может быть привязана ко времени. Можно установить что обработка претензий будет начинаться раз в неделю, по понедельникам, в 10.00. Соответственно, инспектор по качеству будет открывать в понедельник в 10.00 все зарегестрированные претензии и начинать с ними работу. Ему не нужно будет ничего напоминать, он со временем привыкнет начинать неделю с этой работы.

Вот как это будет выглядеть в ОБП.

РИС.4

----------------------------------------------

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

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

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

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

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

Я понимаю, что гуру BPM или какие нибудь модные консалтеры по проектированию бизнес-процессов, загрузят меня разными терминами, типа - BPA, BPMs, Process Intelligence, Process Mining, iBPM, ACM и т.д.

Я создавал систему максимально простой, что бы любой не подготовленный человек взялся и делал. А потом можно дойти и до PBMS  и до Gamification.----

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

В следующей части будет очень важный раздел - Внедрение и поддержание процессов.

---ЗЫ: Извиняюсь за ужасное форматирование текста. Копировал с Корп-портала и почему то теперь не могу отформатировать нормально.

pardus.livejournal.com

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



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

Рисунок 1. Пример стратегической карты предприятия ИТ-отрасли

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

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

Какие элементы подвергаются анализу? В первую очередь, ассортимент предлагаемых компанией товаров и услуг. Составляется реестр – полный пакет этих предложений – и производится его анализ. Все ли из того, что мы производим, выгодно, полезно и способствует достижению основных целей? Стоит ли расширить наш ассортимент? Нужно ли сократить его в части невыгодных товаров или услуг? Можно ли невыгодные товары или услуги сделать выгодными (а выгодные – супер-прибыльными?). Составляется перспективный пакет продуктов и услуг, для которого и будет производиться моделирование бизнес-процессов. Для продуктового анализа можно, например, использовать матрицуBoston Consulting Group (рисунок 2).

Рисунок 2. Матрица Boston Consulting Group. В применении к теме статьи проектирование бизнес-процессов наиболее актуально для «звезд» (в том числе потенциальных) и «дойных коров». 

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

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

Команда участников

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

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

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

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

Рисунок 3. Пример деления бизнес-процессов среднего предприятия. Для крупных – просто добавьте один-два этажа вниз… 

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

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

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

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

Вопрос: Может ли команда, сформированная только из сотрудников предприятия, не привлекая внешних специалистов, пользуясь некими методиками и здравым смыслом, построить и внедрить новую систему управления – от Стратегической карты до детальных бизнес-процессов, регламентов и т.п.? 

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

Собственно проектирование…

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

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

                    Концентрация усилий на выполнение стратегических целей. Бизнес-процессы, не имеющие влияния на ключевые показатели, разрабатываются в последнюю очередь, либо не разрабатываются вообще. Проведем простейший расчет: для предприятия, имеющего три уровня бизнес-процессов (то есть не очень большое унитарное предприятие) мы имеем 7-8 процессов верхнего уровня, каждый из которых делится на 7-8 БП второго уровня, такой же принцип деления сохраняется и ниже. Как результат, уже на третьем уровне имеем более 350 бизнес-процессов. В среднем, каждый бизнес-процесс состоит из десятка операций, что дает четыре тысячи операций в целом для предприятия. И это только для небольшого! Геометрическую прогрессию до четвертого и пятого уровня предлагаю посчитать самостоятельно. Конечно, пятого уровня детализации требуют только такие монстры, как Газпром или РАО ЕЭС – но и для четвертого уровня число операций оказывается не маленьким. Каждый процесс, каждую операцию, в идеале, нужно оптимизировать, регламентировать и пересматривать хотя бы раз в год или по мере изменения внешних условий. Учитывая количество операций, понимаем, что идеал, как обычно, недостижим, а погоня за ним приведет лишь к неоправданному перерасходу ресурсов. Приходится принимать грустное, но верное решение – взяв стратегическую карту, проектировать лишь те бизнес-процессы, которые соответствую указанным в ней целям. И, если уборка внутренней территории не влияет ни на одну из целей или подцелей стратегической карты, не воздействует ни на один показатель из ССП – то пусть ее регламентируют сами уборщики. Хотя бы до тех пор, пока мы не разобрались окончательно с производством, сбытом и снабжением…

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

                    Не забывать при проектировании задавать основные параметры бизнес-процесса (рисунок 5).

Рисунок 5. Не забудьте указать параметры бизнес-процесса.

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

                    Оценка проблемности и важности процесса. Также позволяет понять, какие процессы следует проектировать сразу, а какие могут и подождать. Среди основных критериев здесь могут быть рассмотрены: 1) критичность для бизнеса. То есть насколько неправильное исполнение процесса может навредить компании – повысить затраты, привести к потере клиента, задержать принятие важного решения… 2) Частота повторения процесса (редко, часто, регулярно). 3) Количество передач ответственности в рамках одного процесса, например, от подразделения к подразделению. Такие процессы потенциально опасны и тянут за собой множество проблем.

                    Лидеры по всем трем номинациям – явные кандидаты к проектированию и оптимизации.

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

stud24.ru

Этапы процесса разработки бизнес-модели - Информационные технологии и моделирование бизнес-процессов Библиотека русских учебников

Корпорация Rational Software в 1999 году выпустила на рынок структурированную базу знаний под названием Rational Unified Process (RUP), которая является набором исчерпывающих рекомендаций для создания практически любых м моделей и программных продуктов. Вобрав в себя опыт лучших разработок, RUP подробно описывает когда, кто и что должен делать в проекте, чтобы в результате получить смоделированную систему установленных терм ины, с определенной функциональностью и в рамках отведенного бюджету.

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

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

Схема процесу розробки

Рис189. Схема процесса разработки

Вся разработка. ПО рассматривается в RUP как процесс создания модулей. Любой результат работы проекта, то исходные тексты, объектные модули, документы, передаваемые пользователю, модели - это подкласс си всех модулей проекта. Каждый участник проектной группы создает свой модуль и несет за него ответственность: программист создает программу, руководитель - проектный план, а аналитик - модели системы RUP - до зволяе определить когда, кому и какой модуль необходимо создать доработать или использоватьати.

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

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

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

В фазе исследования уточняются требования, выполняется высокоуровневый анализ и проектирование для построения базовой архитектуры; разрабатывается план для фазы построения

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

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

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

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

Понятие риска и его влияние на разработку модели. После завершения начального этапа утверждения проекта, в фазе исследования (рис189) рассматриваются вопросы четкого определения рисков для проекта, м могут затруднить или сделать невозможным его выполнение. Имеющиеся риски классифицируют по следующим основным категориямями:

o риски, связанные с требованиями;

o технологические риски;

o риски, связанные с квалификацией персонала

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

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

Сущность технологического риска заключается в соответствии выбранной для реализации проекта технологии и требованиям самого проекта. Лучшим способом определения степени технологического риска - построение протот типа системы (или модуля системы) на основе выбранной технологии. Специалисты-практики рекомендуют при этом испытать несколько способов реализации для выбора оптимального вариантту.

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

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

. Резюме

Для моделирования бизнес-процессов используется несколько различных методов, в основе которых лежит как структурное, так и объектно-ориентированный подходы к моделированию: SADT (IDEF0) IDEF3; DFD; ARIS; Erics sson-Penker; Rational Unified Process, причем последние три метода используют UM.

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

. Ключевые слова

Бизнес-процесс, моделирование, модель, варианты использования (Use Case), диаграмма, каноническая диаграмма, UML, нотация, класс, ассоциация, кратность, объектно-ориентированный метод, процесс разработки бизнес-модели и риск.

. Вопросы и задания для обсуждения и самопроверки:

►. Дайте означення діаграми як засобу UML.. Які діаграми входять до складу інтегрованої моделі складної системи?

►. Дайте означення діаграми та нотації.. Проілюструйте поняття кратності у визначенні нотації діаграми класів.

►. Які є переваги об'єктно-орієнтованих методів моделювання?. Опишіть етапи розробки бізнес-моделі.

uchebnikirus.com