Ваш бизнесможетбольше!
 Скачать 3 Mb.
|
|
Небольшая организация (10–100 человек) Возможные цели описания процессов (моделирования) в небольшой организации: Четкое определение зон ответственности руководителей 1. по ключевым направлениям деятельности. Описание деятельности в формализованном виде для регламентации ключевых процессов организации сбыт, закупки, бюджетирование, управление проектами и т. д. Использование описаний процессов при создании документов инструкции по выполнению процессов, положения о взаимодействии. Анализ и улучшение деятельности. Подготовка к автоматизации деятельности, в том числе про. цессов. Первые шаги по созданию культуры процессного управления 5. у сотрудников (обучение процессному ви´дению). Средняя организация (100–1000 человек) Возможные цели описания процессов (моделирования) в организации среднего размера: Четкое определение зон ответственности руководителей 1. на всех уровнях управления. Оптимизация взаимодействия структурных подразделений 2. за счет стыковки процессов по входам/выходам. Системное описание процессов в формализованном виде. 3. Централизованное хранение и актуализация моделей процессов. Постоянное использование моделей процессов для регламентации регламенты выполнения процессов, инструкции по выполнению процессов, положения о взаимодействии и т. д 212 Бизнес-процессы. Моделирование, внедрение, управление Тиражирование стандартов деятельности (например, в фи. лиалы). Обучение сотрудников. Автоматизация процессов. Анализ и улучшение деятельности. Развитие культуры процессного управления у сотрудников. Крупная организация (> 1000 человек) Возможные цели описания процессов (моделирования) в крупной организации: Четкое определение зон ответственности руководителей 1. на всех уровнях. Оптимизация взаимодействия структурных подразделений 2. за счет стыковки процессов по входам/выходам. Создание системы процессов организации. Системное описание процессов в формализованном виде на нескольких уровнях (создание так называемой объектной модели организации. Централизованное хранение (в промышленной базе данных) и актуализация моделей процессов. Автоматизация создания регламентирующих документов (при 4. помощи выгрузки из среды моделирования на основе стандартных шаблонов. Формирование нормативно-методических документов регламенты выполнения процессов, инструкции по выполнению процессов, положения о подразделениях, должностные инструкции. Формирование других отчетов штатное расписание, карточки должности, карта грейдов * , цели и показатели для управления процессами и т. д Документ показывает количество должностей в каждом подразделении, номер грейда для каждой должности, количество сотрудников на должности. Глава 4. Описание бизнес-процессов организации 213 Описание и регламентация процессов управления на всех 5. уровнях. Анализ возможных изменений (реализация сценариев что 6. если) в модели организации 1) создание нового подразделения с передачей ему операций процессов других подразделений) ликвидация подразделения с передачей его процессов другим подразделениям. Тиражирование стандартов деятельности (например, в фи. лиалы). Выполнение внутреннего аудита. Подбор персонала (на основе подробной информации о выполняемых сотрудником процессах). Обучение сотрудников. Автоматизация процессов. Анализ и улучшение деятельности. Управление знаниями о деятельности организации. Вовлечение руководителей и сотрудников подразделений 14. в работу по описанию и стандартизации деятельности орга- низации. Развитие культуры процессного управления у сотрудников. 4.2. Что нужно для успешного описания процессов в масштабах организации? Любой сотрудник вполне способен описать несложный процесс. Однако полученная схема будет лишь в некоторой степени отражать реальность. Можно долго спорить о преимуществах той или иной нотации (методики) для описания данного процесса. Нос точки зрения моделирования процессов в масштабах компании эти вопросы 214 Бизнес-процессы. Моделирование, внедрение, управление и споры будут несущественны. Выбор нотации, как и другие частные вопросы, не определяет успех работы по описанию и регламентации процессов организации в целом. Эту задачу можно решить только в случае системного, комплексного подхода, учитывающего множество различных факторов. Рассмотрим основные аспекты, которые должны знать и учитывать руководители при построении в организации системы работы по описанию (моделированию) бизнес-процессов. 4.2.1. Формулировка целей описания процессов Прежде всего необходимо четко определить цели описания процессов. Нечеткость или неадекватность целей приведет к некорректному выбору средств их достижения. В результате деньги и время организации будут потрачены впустую. Пример. В торговой компании среднего размера директор поставил задачу сотруднику затри месяца подробно описать шесть ее основных процессов. При этом конкретные требования к результату (формат описания, степень детализации процессов и т. д) установлены небыли. В итоге удалось описать лишь незначительную часть процессов, а сотрудник перешел работать в другую организацию. Очевидно, что цели описания процессов были поставлены руководителем некорректно. Цели описания процессов должны быть четко сформулированы в проектном документе. Возможными целями описания могут быть: анализ и последующая оптимизация процессов; — разработка регламентирующих документов; — подготовка к автоматизации процессов; — прочее. — В 2011 году компания BPTrends провела исследования в области моделирования бизнес-процессов. Респондентами стали представители почти 16 000 зарегистрированных участников сообщества Глава 4. Описание бизнес-процессов организации и посетители соответствующего сайта (Северная Америка, Европа — 32% и т. д. Поскольку деятельность BPTrends охватывает весь диапазон вопросов, составляющих часть понятия «бизнес-процесс», к исследованию были привлечены управленцы и практики, заинтересованные в комплексном подходе к процессно- му управлению Моделирование процессов — актуальный метод, используемый практиками в сфере процессного управления, чтобы получать, систематизировать и передавать информацию о бизнес-процессах. Модели процессов могут быть изображены на рабочей доске, бумаге или представлены в цифровой форме в различных видах программного обеспечения для их моделирования. Они могут быть как абстракциями, определяющими фазы деятельности, таки детализированными изображениями осуществленных шагов и принятых решений входе конкретной операции. Например, менеджер может нарисовать на листе бумаги три прямоугольника для представления трех фаз, через которые обычно проходит его организация входе аудита. Специалист по программному обеспечению может изобразить множество прямоугольников со стрелками и ромбами для точного отражения решений, которые требовались для одобрения нового кредитного счета. И то и другое можно назвать моделями процесса, поэтому в рамках этого исследования термин моделирование процесса использовался очень широко для возможности рассмотрения всех видов моделирования…» В исследовании BPTrends приводится интересная диаграмма, представленная на рис. 4.2.1. По сути, на ней показаны цели моделирования (описания) бизнес-процессов. На первом месте (81%) стоит пункт Вместе с реинжинирингом и совершенствованием процессов. Это означает, что около 81% компаний используют моделирование как средство для описания, анализа и оптимизации бизнес-процессов. 216 Бизнес-процессы. Моделирование, внедрение, управление На втором месте — пункт Для передачи информации о процессе. Иными словами, это использование описания процессов для последующей регламентации, размещения информации о процессах на портале организации и т. п. Нотация моделирования процессов Руководителям нужно определиться с требованиями к описанию процессов, в том числе выбрать нотации для создания моделей. Следует выявить внутренних потребителей и понять их запросы. Например, руководителям подразделений нужно будет использовать описания процессов для формирования регламентирующих документов. Департамент по работе с персоналом заинтересован в выгрузке из системы моделирования должностных инструкций. Важно понимать, что описание процесса в среде моделирования содержит гораздо больше информации, чем показано на его графической схеме независимо от нотации. Но именно эта информация необходима при регламентации, формировании отчетов и т. д. При выборе нотации полезно обратить внимание наследующее. Если описание процессов делается для создания регламентирующих документов, то схемы процессов должны быть просты и интуитивно Как подготовку к внедрению ERP-систем Как подготовку к внедрению Для удовлетворения требований к документированию бизнес-процессов, включая согласование Как подготовку к разработке программного обеспечения Как часть инициатив по преобразованию бизнеса Для уточнения определенной совокупности деятельности Для передачи информации о процессе Вместе с реинжинирингом и совершенствованием процессов 20 40 60 80 Рис. 4.2.1. Как вы используете моделирование бизнес-процессов? Глава 4. Описание бизнес-процессов организации 217 понятны сотрудникам организации, информативны при минимальном наборе используемых графических символов. Нет смысла усложнять графическое представление — полезную информацию вполне можно вывести в нормативно-методические документы в виде таблиц и текста. Выбранная нотация должна быть понятна большинству сотрудников без специального обучения и длительного освоения. Конечно, можно заставить людей описывать процессы в любых нотациях (например, в UML * ) при помощи совершенно разных средств моделирования, но затраты на внедрение таких нотаций/систем обычно значительны. Чрезмерно сложная нотация и средство моделирования сделают методы процессного управления доступными для узкого круга профессионалов из отдела организационного развития или отдела, а преимущества процессного подхода не будут реализованы в полной мере. Замечу, что если предполагается описывать процессы исключительно в целях последующей автоматизации, то лучше всего использовать нотацию BPMN ** Сформулируем простые критерии для выбора нотации моделирования процессов на операционном уровне: в нотации представлен минимально необходимый набор графических элементов для описания процессов типа Work Flow поток работ); быстрота и низкая трудоемкость создания графических схем для целей регламентации; схемы процессов просты и понятны всем сотрудникам даже без специального обучения; простота в обучении (нет необходимости привлекать дорогостоящих специалистов со стороны — обучение можно проводить силами сотрудников отдела организационного развития); схемы процессов являются кросс-функциональными, что удобно для описания сквозных процессов организации * Unify Modeling Language — унифицированный язык моделирования. ** Business Process Modeling Notation — нотация и модель бизнес-процессов. 218 Бизнес-процессы. Моделирование, внедрение, управление. Репозиторий и среда моделирования процессов Представьте, что вам поручили разработать регламент выполнения какого-то процесса компании. Ситуация складывается удачно — у вас стоит MS Visio. Вы создаете новый файл, начинаете рисовать схему процесса, затем сохраняете ее, включаете в регламент, согласуете его с руководителями и т. п. Через два месяца нужно сделать еще один документ по той же процедуре. Кроме вас еще несколько руководителей и специалистов компании время от времени мастерят регламенты процессов. В результате в организации появляется множество схем, описанных в различных форматах и инструментах. Они хаотично хранятся в файлах на компьютерах разных пользователей. Как можно оценить такое положение дел Неужели так работать удобно Скорее всего, нет. Сложившуюся ситуацию можно охарактеризовать так: процессы моделируют разные сотрудники без всякой коорди- — нации; единого стандарта моделирования процессов нет; — единого места для хранения схем процессов нет; — внесение изменений в регламентирующие документы требует ручной работы; доступ сотрудников к информации по процессам затруднен; — информация, формализованная в схемах и описаниях процессов, быстро устаревает. С ростом количества схем процессов ситуация становится угрожающей. Руководство компании понимает полезность описания, анализа и регламентации процессов, ноне готово развивать и поддерживать такую работу, осознавая запутанность существующей практики моделирования и регламентации процессов. В таких условиях нужен электронный репозиторий бизнес- процессов, ведь нельзя с самой ценной для компании информацией обходиться как с мусором Глава 4. Описание бизнес-процессов организации 219 А если в вашей компании полный порядок, означает ли это, что: создан и используется единый стандарт для описания бизнес- — процессов; все схемы процессов хранятся в специализированной базе — данных; выполняется описание процессов в специализированной системе с последующей автоматической генерацией (выгрузкой) регламентирующих документов вили в базе данных в привязке к процессам можно хранить любую нужную информацию (формы документов, показатели, фотографии, документы с техническими характеристиками в формате и т. д.); обеспечен легкий и быстрый доступ сотрудников к информации по процессам (например, через внутренний портал)? Ответы да говорят о том, что в компании создан электронный репозиторий бизнес-процессов. Он может быть сформирован с использованием среды моделирования бизнес-процессов. Итак, репозиторий — это специализированный программный продукт, позволяющий создавать, хранить, актуализировать и использовать любую информацию о бизнес-процессах компании. Безусловно, репозиторий бизнес-процессов полезен — это база знаний о деятельности компании. Если она будет полной и актуальной, то обеспечит возможность: быстро актуализировать модели бизнес-процессов; — с минимальными трудозатратами формировать регламентирующие документы: регламенты выполнения бизнес-процессов; • регламенты управления бизнес-процессами; • 220 Бизнес-процессы. Моделирование, внедрение, управление технологические инструкции; • положения о подразделениях; • должностные инструкции сотрудников; • прочее; • быстрый и легкий доступ к информации по процессам через — интерфейс; возможность использовать накопленные знания для автома- — тизации; возможность использовать информацию о процессах для обучения новых сотрудников; прочее. — Если у компании несколько филиалов, тов репозитории можно накапливать информацию и обмениваться опытом эффективного выполнения процессов в разных регионах и городах. Создание электронного репозитория бизнес-процессов — это инвестиция в будущее компании. Почему Судите сами внедряя репо- зиторий, вы: выполняете описание, анализ и улучшаете бизнес-процессы — организации; приучаете руководителей и специалистов мыслить категориями процессов (другими словами, создаете в компании культуру процессного управления); делаете систему управления прозрачной; — получаете возможность со временем избавиться от незаменимых персонажей (разгерметизировать деятельность отделов и сотрудников). Особенно интересно связать процессы репозитория с процессами, выполняемыми в различных автоматизированных системах. Вызнаете, например, что ваша система поддерживает определенные Глава 4. Описание бизнес-процессов организации 221 функции. Но как, в каких бизнес-процессах, когда, кто и с какой эффективностью их выполняет Модели бизнес-процессов в репозито- рии могут прояснить ситуацию. Сразу станет понятно, какие функции системы в каких бизнес-процессах применяются. Репозиторий предоставляет широкий спектр возможностей. Но их использование требует упорной работы по внедрению про- цессных технологий. Успех зависит от последовательного и твердого желания собственников и топ-менеджмента компании использовать эти технологии. При выборе среды моделирования, которая позволит создать ре- позиторий бизнес-процессов организации, важно обратить внимание наследующие ее возможности: простота и интуитивная понятность интерфейса; — легкость моделирования бизнес-процессов; — хранение информации о деятельности компании в базе данных (например, в СУБД MS SQL расширение объектной модели для описания различных атрибутов процессов и т. д.; размещение моделей на портале организации; — работа в многопользовательском режиме. — Пример. Вы описываете процесс обслуживания оборудования. Для ряда операций нужно вывести в регламент текстовое описание, фотографии агрегатов, список используемых расходных материалов и т. д. Это легко сделать, используя возможности среды моделирования. После внесения информации в систему готовый регламент обслуживания оборудования генерируется в виде файла MS Word засчитанные минуты. Теперь предположим, что при выполнении технического обслуживания отмечена возможность более быстрого и технологичного выполнения какой-то операции. Мастери механик обсуждают эту ситуацию, формализуют знания и заносят информацию 222 Бизнес-процессы. Моделирование, внедрение, управление в репозиторий процессов. В дальнейшем сотрудники другой смены других филиалов, новые сотрудники и т. д) смогут не только ознакомиться с регламентом выполнения процесса, но и посмотреть рекомендации по наиболее эффективному способу выполнения работы. Со временем этот способ можно будет внести в регламент в качестве обязательного. Описанная ситуация годится для любого бизнес-процесса независимо от объекта деятельности. Говоря о практическом использовании репозитория, следует отметить, что: для поддержания репозитория требуются квалифицированные специалисты; работать с репозиторием нужно по определенным, четко установленным правилам. Качество информации в репозитории зависит от квалификации сотрудников, моделирующих процессы. Кроме того, эту информацию нужно постоянно актуализировать. Руководство компании должно понимать можно купить программу для бизнес-моделирования, потратив некоторую сумму, но купить репозиторий нельзя, его нужно создать и поддерживать силами организации. Приведу аналогии если не делать ремонт, то крыша склада прохудится, а товар испортится. Если не менять изнашивающиеся детали оборудования, то оно встанет. Если не использовать на практике и не актуализировать информацию о бизнес- процессах в репозитории, то он быстро станет ненужным хранилищем мертвого массива данных. Важно знать основные возможности среды моделирования процессов, которую предполагается использовать для создания репози- тория. Современные программные продукты, предназначенные для описания процессов, как правило, хранят информацию в промышленной базе данных (например, в СУБД MS SQL-Server). Эти системы позволяют создавать сложные, иерархические справочники процессов, Глава 4. Описание бизнес-процессов организации 223 подразделений и должностей, документов. С системой могут одновременно работать несколько пользователей. Информация о внесенных изменениях сохраняется. При помощи среды моделирования процессов формируется так называемая объектная модель организации. Она должна постоянно поддерживаться в актуальном состоянии. Ценность модели в том, что она позволяет формировать регламентирующие документы разного типа и другие необходимые отчеты, дающие ответ почти на любой вопрос о деятельности организации. Модель деятельности компании становится прозрачной для руководителей. Сотрудникам доступна информация о процессах (графические схемы, описания входов/выходов, требования к сроками т. д.). Потенциал среды моделирования должен быть адекватен поставленным задачам. У более сложных и дорогих систем больше возможностей, ноне все они востребованы в организации, в том числе из-за отсутствия подходящих специалистов. Даже в самих компаниях, поставляющих системы моделирования, количество профессионалов, глубоко разбирающихся в функционале системы и умеющих его использовать, весьма ограничено. Найти таких специалистов на рынке непросто. Поэтому мощные функциональные возможности среды моделирования могут оказаться ненужными. Но и покупка слишком простого или морально устаревшего программного обеспечения для моделирования процессов может привести к снижению эффективности деятельности по описанию и регламентации процессов организации. В исследовании BPTrends приводится любопытная диаграмма см. рис. 4.2.2) по свойствам среды моделирования процессов, наиболее важных для пользователей. На первом месте — Способность сохранять модели и данные о процессах в репозитории». Речь идет о базе данных, в которой хранится комплексная модель организации. На втором месте упомянута возможность создавать сложные иерархические модели процессов. На третьем — использование стандартной нотации или языка моделирования Бизнес-процессы. Моделирование, внедрение, управление В современных компаниях среда моделирования бизнес- процессов — один из базовых инструментов, обеспечивающих развитие и совершенствование системы управления. Обратите внимание, что только 10% опрошенных считают важной способность легко переходить от модели к коду программного обеспечения. Для остальных важнее оказались другие требования. Например, 36% указали на Способность создавать простые модели процессов, а 56% — на Способность сохранять модели и данные о процессах в репозитории». Эти факты говорят о том, что компаниям, которые используют моделирование процессов для анализа, оптимизации и документирования (регламентации, нужны: простая, но стандартная нотация моделирования; — надежный инструмент, позволяющий создавать сложные, многоуровневые модели процессов и хранить их в репозито- рии (базе данных. Методики описания процессов Чтобы успешно выполнить проект по созданию системы работы по описанию процессов, нужны нормативно-методические документы (методики, стандарты, среди которых 10 20 40 30 60 50 Способность сохранять модели и данные о процессах в репозитарии Способность создавать комплексные (вложенные) модели процессов Поддержка стандартной нотации или языка моделирования Способность размещать модели на сайте для более широкого использования Способность создавать простые модели процессов Способность сохранять информацию о ролях, затратах и другие данные, связанные с деятельностью Способность выполнять имитацию Способность распечатывать модели Способность легко переходить от модели к коду программного обеспечения Другое, пожалуйста, уточните Рис. 4.2.2. Какие три свойства средств моделирования процессов высчитаете самыми важными Глава 4. Описание бизнес-процессов организации 225 стандарт описания бизнес-процессов (Соглашение о моделировании бизнес-процессов»); стандарт управления изменениями модели организации; — инструкция по администрированию среды моделирования; — прочее. — К сожалению, вопрос методического обеспечения проекта не всегда учитывается руководителями, принимающими решения о приобретении и внедрении среды моделирования процессов. Наличие необходимых специалистов Важнейший фактор успешного внедрения — наличие в организации нескольких специалистов, которые могут: разрабатывать и изменять систему процессов организации; — согласовывать процессы по входам/выходам; — проводить интервью, получать и структурировать информацию по процессам; описывать процессы в нужных нотациях в среде моделиро- — вания; настраивать среду моделирования, в том числе формировать шаблоны отчетов для выгрузки регламентирующих документов; управлять изменениями объектной модели организации; — обучать сотрудников организации принципами методам описания процессов; прочее. — Разработка и внедрение в организации системы описания процессов довольно сложный и длительный (3–6 месяцев) проект, для успешного выполнения которого руководители организации должны выделить адекватные человеческие и финансовые ресурсы 226 Бизнес-процессы. Моделирование, внедрение, управление Пример. Вторгово-производственной компании среднего размера приняли решение описывать бизнес-процессы. После проведения формального тендера приобрели среду моделирования процессов. Одному из сотрудников организации было поручено ее использовать. На методическое обеспечение, обучение персонала, настройку системы (справочники, отчеты) денег не выделили. В результате уполномоченный сотрудник в течение нескольких месяцев пытался описывать процессы на свой страхи риск. Полученные модели оказались весьма сомнительного качества. Кроме того, попытка документировать процессы окончилась неудачей, поскольку а) заранее небыли продуманы требования к информации, которую следовало использовать в описаниях процессов б) у сотрудника, работающего со средой моделирования, не хватило квалификации для настройки необходимых шаблонов отчетов. Объектная модель организации В этом параграфе мы обсудим вопрос создания так называемой объектной модели организации. Моделирование организации предполагает определение и подробное описание таких объектов, как: процессы; — владельцы/исполнители процессов (подразделения, должности, бизнес-роли); ресурсы: документы, файлы, ТМЦ — * ; инициирующие и завершающие события; — термины; — цели и показатели деятельности; — физические лица, занимающие соответствующие должности; — прочее. — * ТМЦ — товарно-материальные ценности Глава 4. Описание бизнес-процессов организации 227 Каждый из этих объектов обладает рядом атрибутов. Например, для него могут быть определены название, тип, текстовое описание, требования к срокам. По ходу моделирования объекты контактируют между собой, и эти связи также могут иметь определенный тип и соответствующие атрибуты. В результате моделирования появляется объектная модель организации упорядоченная совокупность объектов, связанных между собой определенными способами. Четкая структура этой модели и наличие связей позволяют в дальнейшем получать любые регламентирующие документы (регламенты, инструкции, положения) и необходимые отчеты. Объектная модель реализуется только в виде соответствующей базы данных. Ее структуру, разработанную для решения задач бизнес- моделирования, можно называть метамоделью ** организации. На рис. 4.3.1 показано, как в результате деятельности по моделированию с использованием метамодели получается комплексная объектная модель организации * В некоторых западных подходах модель такого типа называют Enterprise Architecture. ** В среде моделирования Business Studio используется следующее определение метаданные — описательная информация о структуре и смысле данных. Деятельность по моделированию Объектная модель организации Метамодель организации Информация о деятельности организации Таблица Таблица Таблица Рис. 4.3.1. Связь объектной модели и метамодели организации 228 Бизнес-процессы. Моделирование, внедрение, управление Метамодель организации, по сути, — это совокупность связанных таблиц СУБД (системы управления базы данных, иона может расширяться по мере необходимости. Например, для такого класса объектов, как должность, можно дополнительно определить следующие атрибуты: наименование должности; — номер грейда; — лицо, назначающее сотрудника на данную должность; — лицо, осуществляющее представление на данную должность; — показатели оценки эффективности; — прочее. — Для успешного внедрения системы описания процессов нужны квалифицированные специалисты, способные грамотного осуществлять изменения (доработки) в метамодели организации. Замечу, что далеко не в каждой среде моделирования есть средства управления метамоделью. Но, как показывает практика, эта возможность очень ценна и востребована при практическом описании процессов организации. Архитектура типовой среды моделирования процессов Сейчас на рынке представлено множество программных продуктов для моделирования деятельности организации. Эти продукты относятся к так называемым средствам Business Process Architecture или Enterprise Architecture, то есть программным инструментам, предназначенным для проектирования бизнес-процессов и бизнес-архитек туры компании. Руководителями специалистам, внедряющим процессный подход, важно понимать общую архитектуру систем такого класса. Рассмотрим архитектуру типовой среды моделирования процессов, представленную на рис. 4.4.1. Такая среда, как правило, имеет Глава 4. Описание бизнес-процессов организации 229 модульную структуру, которая определяется соответствующими сервисами. В конкретных системах сервисы могут объединяться в рамках единых программных решений, а также существовать и использоваться по отдельности в виде модулей. Информация о деятельности организации (справочники процессов, подразделений, документов, схемы процессов) хранится в промышленной базе данных, например MS SQL Server. Есть отдельный сервис, который используется для администрирования создания/ изменения/архивирования баз данных, создания новых пользователей, назначения прав доступа и т. д. Сервис управления метамоделью — важнейший инструмент бизнес-моделирования. Он позволяет расширять метамодель, предлагаемую поставщиком системы, и создавать новые списки, перечисления, атрибуты для существующих классов объектов. В некоторых системах предусмотрена возможность определять новые классы объектов и связей между ними. Фактически в такой системе Сервис формирования отчетов Сервис администрирования базы данных Сервис управления метамоделью Сервис описания процессов Сервис выгрузки моделей в Сервис администрирования Сервис анализа бизнес-процессов База данных SQL Рис. 4.4.1. Архитектура типовой среды моделирования процессов 230 Бизнес-процессы. Моделирование, внедрение, управление доступно спроектировать любую нотацию, которая может потребоваться в организации. Возможность расширения метамодели важна для полного и адекватного моделирования, решения практических задач, возникающих у разных групп пользователей внутри организации. Основной сервис среды моделирования — сервис описания, где можно: создавать различные справочники: — процессов; • подразделений; • должностей; • документов; • терминов; • прочее; • формировать схемы: — процессов; • организационных структур; • прочее • ** ; описывать объекты модели: — заполнять текстовые поля например, указывать название процесса, его начало, завершение, требования к срокам); формировать списки например, указывать должностных лиц, которые согласуют требования к выполнению процесса); выбирать нужные типы например, указывать тип подразделения департамент или «отдел»); задавать количественные параметры например, номер грейда, количество ставок на должности или среднее время выполнения процесса); прочее; • * Условное название модуля ** Зависит от функциональных возможностей конкретной среды моделирования Глава 4. Описание бизнес-процессов организации 231 формировать отчеты: — выгружать регламентирующие документы регламенты процессов, инструкции по выполнению процессов, положения о подразделениях, должностные инструкции); выгружать другие специализированные отчеты например, отчет по движению документов — где создается, кем согласуется, кем утверждается и т. п.); осуществлять анализ и изменение объектной модели: — создавать/корректировать/удалять процессы, подразделения, документы; переназначать исполнителей процессов; • выявлять процессы без назначенных исполнителей; • выявлять документы, которые никто не использует; • прочее. • Как правило, основные пользователи сервиса описания процессов квалифицированные бизнес-аналитики, которые проводят интервью, структурируют информацию и заносят ее в систему в виде различных моделей. В некоторых случаях руководство организации принимает решение вовлекать в работу сотрудников подразделений, которые также используют часть функциональных возможностей в рамках своих полномочий. При выборе системы руководителям компаний стоит уделить серьезное внимание анализу функциональных возможностей и удобства использования модуля описания процессов. Этот аспект важнее, чем выбор той или иной нотации моделирования. Рекомендуется попробовать все интересующие системы, описав в них один- два пилотных процесса. Для управления командной работой служит сервис администрирования, в рамках которого: выполняются настройки интерфейса системы; — выполняются настройки ряда справочников; — создаются/редактируются группы пользователей системы 232 Бизнес-процессы. Моделирование, внедрение, управление определяются права для групп пользователей и отдельных — пользователей; выполняются настройки, необходимые для отслеживания изменений в системе; прочее. — Сервис формирования отчетов служит для разработки шаблонов различных отчетов (генератор отчетов. При помощи определенного функционала (в системах это может быть реализовано по-разному) квалифицированный пользователь проектирует запрос к базе данных и определяет формат вывода информации в документ MS Word или MS Excel. При построении отчета его тестируют на реальной или специально подготовленной для этого объектной модели. Готовые отчеты доступны конечным пользователям системы. Из системы можно выгружать готовые к согласованию и утверждению нормативно-методические документы (регламенты, положения, инструкции) и другие нужные в практической работе документы. При выборе системы руководитель должен выполнить анализ сервиса формирования отчетов. Лучше выбирать такую систему, генератор отчетов которой легко освоит не только программист специалист по запросам к СУБД и написанию кода, но и обычный бизнес-аналитик. Очень полезен сервис выгрузки моделей в формат. Он используется для размещения моделей процессов на интранет- или интернет-сервере организации. Все сотрудники (имеющие соответствующие права) могут оперативно просматривать данные на этом сервере, то есть вся регламентирующая информация по процессам становится доступной рядовому персоналу. Анализ процессов выполняется на сервисе анализа. Как правило, он дает возможность проводить имитационное моделирование процессов, анализировать затраты и т. д. Современная среда моделирования бизнес-процессов — это сложный пакет программных продуктов, для успешного внедрения которого организации нужны сотрудники с нужной компетенцией и опытом Глава 4. Описание бизнес-процессов организации 4.5. Структурные модели процессов организации В этом параграфе мы рассмотрим особенности использования структурных моделей при описании процессов организации. Под структурной будем понимать модель, включающую в себя упорядоченный по определенному принципу набор процессов (групп процессов) с указанием основных связей между ними. Основное назначение структурной модели — показать, как устроен бизнес организации, раскрыть информацию об основных группах процессов и их взаимосвязях. Структурная модель не показывает последовательность выполнения процессов во времени. Структурные модели можно использовать локально (не в системе процессов организации) для схематичного описания состава процессов, декомпозированных наследующий уровень. Например, такая структурная схема может быть представлена в регламенте двухуровневого процесса. Для формирования структурных моделей используются соответствующие нотации IDEF 0 , ARIS Value Added Chain, Value Stream Map (информационные потоки) компании Toyota, модель цепочек создания ценности и др. Информация о них содержится во многих публикациях, поэтому в своей книге я не стану касаться этого вопроса. Структурные модели процессов, как правило, применяются для: описания, анализа бизнес-модели организации и определения возможных направлений ее реорганизации; разработки системы бизнес-процессов организации по принципу сверху вниз»; системного описания процессов, которые необходимо автоматизировать (например, в ERP-системе); описания состава процессов, декомпозированных наследующий уровень (несистемное, фрагментарное использование). Рассмотрим деятельность торговой компании (розничная торговля продуктами питания. На рис. 4.5.1 показан пример структурной Управление финансами Управление персоналом АХОИн женерно -тех ни ческ ое обеспечение Обеспечение деятельности Управление дивизионом Управление направлением Магазин Уп р ав лени е сетью Розничные продажи продажами в целом, под, по направлениям (к ус та м ), в отдельном маг азине У п р а вл е н и е товарными категориями потребностей потребителей в товаре (ассортимент цена к аче ст во ) Ф и зи че ск ая поставка товара в с ет ь Комп лексное обеспечение деятельности маг азинов М аг аз и н как п р о ду кт От кр ы ти е новых магазинов Развитие форматов магазинов Развитие Управление развитием Развитие бизнеса Комп лексное развитие форматы магазины С ТМ С тратег и че ское управление Марке тинг Р ек лама и Оперативное управление Управление бизнесом Управление ассортиментом Насыщение сети товаром Зак уп кат ов ара Управление поставкой товара в сеть Тр ан спор тн ая и складская логистика По д д ерж а ние форматов магазинов Оформлен ие Инфр астр ук тура Инженерное обеспечение Работа с поставщиками Уп рав ление товарными запасами Ценообразование Рис. 4 .5 .1. Пример структурной модели торговой компании Один из возможных вариантов представления Глава 4. Описание бизнес-процессов организации 235 модели процессов, выполненной без использования специализированной нотации на основе анализа цепочек создания ценности, осуществляемых компанией. На рис. 4.5.1 видно, что в модели выделено семь групп процессов. Цель ее построения — демонстрация возможного варианта определения и группировки процессов торговой компании. Такая модель может быть представлена руководителям верхнего уровня для согласования. В дальнейшем модель используется при построении системы процессов организации. На рис. 4.5.2 та же модель, что и на рис. 4.5.1, только выполненная в стандарте Анализируя рис. 4.5.2, отмечу, что многочисленные стрелки, которые обычно представлены на схемах IDEF 0 , не так уж важны руководителям бизнеса для понимания и использования модели. Менеджеры крупной торговой компании, проработавшие в бизнесе много лет, хорошо представляют себе основные результаты работы каждого структурного подразделения (ассортиментная матрица, план продажи закупок и т. п. Поэтому загромождение структурной схемы стрелками скорее развлечение, а не деятельность бизнес-аналитика, полезная для управления. Нужно стремиться минимизировать количество стрелок, сохраняя при этом информативность схемы. Однако в случае проектирования компании с нуля проработка основных связей на структурной схеме очень полезна. Но такие случаи на практике встречаются редко. Вопрос пользы структурных моделей для решения задач бизнес- моделирования спорный. С моей точки зрения, построение сложной, многоуровневой системы процессов организации водной модели IDEF 0 (или в другой нотации) излишне. Если соблюдать все формальные правила, тов такой модели может получиться семь-восемь уровней декомпозиции. Реальную же ценность для последующего описания и регламентации имеют один-два нижних уровня, где выполняются конкретные операции и осуществляется реальный документооборот. Именно на этих уровнях процессы можно описать в формате Work Flow и при помощи этих описаний сформировать регламенты работы сотрудников (регламент процесса, инструкция по выполнению Поддержание форматов магазинов Модель торговой организации 1 9 .0 2 .2 0 1 2 D R AF T RE C O MME N DED N O TE S : 1 2 3 4 5 6 7 8 9 1 0 P U B LI C AT IO N MODE: АО Уп р а в л е н и е бизнесом А1Уп р а в л е н и е товарными категориями А2Нас ы щ е ни е сети товаром А3По д д ерж а ние форматов магазинов А4Ро зни чные продажи А5Обе спечение деятельности А7Разви тие сети А6 TITLE : Мо дель торговой организации Цели акционеров Ц е липла н ы О тч е тн ость Товар от поставщиков ТМЦ для обеспечения работы магазина Де нежные средства потребителей ТМЦ, ПО и прочее Инф о р м ац и я о рынке Ассортиментная матрица То вар, отгруженный с Р Ц Д е нежные средства в банке Товару потребителей Ин ф. оп рода ж а х И н фра, Т М Ц , ПО, прочее Инфр астр ук тура магазина Отчетность Те б о ван и я пора зв и ти ю форма тов Рис . 4 .5 .2. Пример структурной модели процессов торговой компании. Стандарт Модель учебная. Подразделения исполнители процессов не показаны. Обратные связи тоже Глава 4. Описание бизнес-процессов организации 237 процесса» и т. п. Вопрос в том, как разработать адекватный реальному бизнесу иерархический справочник процессов. Если можно обойтись без сложной (понятной только бизнес-аналитику) структурной модели процессов, то и ненужно ее создавать. Примечание. В крупной, давно работающей компании построение сложной структурной модели может не принести ожидаемого результата. Дело в том, что топ-менеджмент вряд ли решится перекраивать весь бизнес по модели в IDEF0. Ас точки зрения регламентации на операционном уровне все верхние уровни (й) в модели IDEF0 бесполезны. Другое дело, если нужно спроектировать новый бизнес. Эта работа выполняется по принципу сверху вниз, так как действующих процессов и самой компании пока нет. Анализ структуры и связей процессов наверх- нем и среднем уровнях полезен для принятия решений о структуре будущей организации и закреплении групп процессов за подразделениями. Итак, структурная модель процессов нужна: бизнес-аналитикам для понимания деятельности организации и создания адекватной системы процессов (в первую очередь для корректного перехода к процессам уровня Work Flow — регламентируемым или автоматически исполняемым в BPMS процессам); руководителям организации для: — уточнения зон ответственности, целей и задач их деятель- • ности; анализа и совершенствования архитектуры бизнеса; • руководителям и бизнес-аналитикам при проектировании нового бизнеса. Замечу, что среди руководителей компаний желающие работать со структурной графической моделью процессов верхнего уровня встречаются редко. Поэтому многоуровневая структурная модель * Этот вопрос подробно обсуждался в главе 3. 238 Бизнес-процессы. Моделирование, внедрение, управление (например, в IDEF 0 ) — удел узкого круга бизнес-аналитиков. В лучшем случае руководители используют диаграмму первого уровня, которую размещают на стенде с нормативно-методической документацией. Модели процессов на операционном уровне В этом параграфе мы рассмотрим модели процессов на операционном уровне. Они отображают последовательность выполнения операций процесса (подпроцессов) во времени. Их обычно называют модели Work Сейчас существует множество нотаций типа Work Flow, при помощи которых можно описывать процессы операционного уровня. Рассмотрим основу формирования моделей и некоторые важные аспекты их применения. Нотации типа Work На рис. 4.6.1 показаны основные элементы, которые используются практически во всех современных нотациях Work Flow. Можно выделить пять основных: События. 1. Операторы логики (по-другому их называют блоки решения, 2. ветвления/развилки, шлюзы/гейтвеи ** ). Операции процесса. Стрелки типа Связь предшествования. Стрелки типа Поток объектов. События служат для определения границ процесса. Они могут указывать на его начало и завершение. Кроме того, возможны промежуточные события, возникающие походу выполнения процесса. Примеры именования событий Поступила заявка клиента на отгрузку * Work flow — поток работ (англ ** Gateway — ворота, шлюз (англ. Глава 4. Описание бизнес-процессов организации 239 продукции», Утвержден план проекта, Подписана накладная, «8.00 понедельника и т. п. Как видно на рис. 4.6.1, в различных нотациях события показаны при помощи разных условных обозначений. Особняком стоит BPMN 2.0 * (см, например, [9]). В рамках этой нотации внутри графического элемента Событие могут присутствовать различные маркеры таймер, сообщение, триггер и т. д. Рис. 4.6.1. Основные элементы нотации Work Процедура системы Business Studio ARIS eEPC BPMN События Операторы логики Операции процесса Стрелки типа Связь предшествования» Стрелки типа Поток объектов» Операторы логики служат для описания ситуаций, связанных с ветвлением процесса. Оно может произойти по разным причинам например, принятие решения, проверка условия. Операторы логики бывают трех типов логическое И, логическое исключающее ИЛИ, логическое неисключающее «ИЛИ». На рис. 4.6.2 приведен пример использования операторов логики при построении схемы типа Work Flow (графические обозначения операторов логики на схеме условные). При использовании логического оператора И (ситуация 1) после операции 1 выполняются операция 2 и операция 3. * Business Process Model and Notation. ** За исключением BPMN. 240 Бизнес-процессы. Моделирование, внедрение, управление При использовании логического оператора исключающее ИЛИ (ситуация 2) после операции 1 выполняется одна из двух операций — 2 или При использовании логического оператора неисключающее ИЛИ (ситуация 3) после операции 1 выполняется операция 2, либо операция 3, либо операции 2 и Условные обозначения для операций процесса (задач, действий, функций) выглядят практически одинаково во всех нотациях типа Work Рис. 4.6.2. Использование операторов логики Ситуация После выполнения операции 1 выполняются операция 2 и операция Операция Операция Операция Логический оператор «и» «и» Ситуация После выполнения операции 1 выполняется либо операция 2, либо операция Операция Операция Операция Логический оператор исключающее «или» «или» Ситуация После выполнения операции 1 выполняется либо операция 2, либо операция 3, либо обе операции — 2 и Операция Операция Операция Логический оператор неисключающее «или» «или» Глава 4. Описание бизнес-процессов организации 241 Важный элемент схемы Work Flow — связи. Они представлены при помощи стрелок определенного вида. Первый тип — стрелки Связь предшествования. Без них построение модели типа Work Flow невозможно. Стрелка Связь предшествования, связывающая две операции, показывает, что вторая операция начинает выполняться только после завершения первой. Можно сказать, что стрелки Связь предшествования демонстрируют развертку процесса во времени. Стрелки Поток объектов используются на схемах типа Work Flow для описания потоков документов и информации * За счет использования событий, операторов логики и стрелок Связь предшествования на схеме Work Flow можно показать сложную логику выполнения процесса во времени. В следующих разделах рассмотрим наиболее известные нотации моделирования. Простая блок-схема Нотация Простая блок-схема» реализована в MS Visio. На рис. 4.6.3 показаны элементы этой нотации и фрагмент соответствующей схемы. В полном объеме нотация применяется редко. Вообще в MS Visio представлено несколько сложных нотаций типа «Блок-схема». Видимо, поэтому они не нашли широкого применения, хотя и были включены в набор нотаций, поставляемых с системой. Нотация Простая блок-схема» в самом доступном и часто используемом варианте содержит всего несколько элементов: процесс; — решение; — ручная операция (реже); — документ; — данные; — стрелка (для отображения связей между объектами схемы При необходимости их можно использовать для описания потоков материальных объектов 242 Бизнес-процессы. Моделирование, внедрение, управление При помощи этой нотации можно показать потоки данных, если необходимо описывать процессы для автоматизации. Рассмотрим некоторые особенности применения простой блок- схемы, в частности применение стрелок. Сотрудники компании, формирующие схемы при помощи простой блок-схемы, придерживаются двух подходов: не именуют стрелки вообще; — стараются присваивать стрелкам, связывающим элементы схемы, простые и понятные названия. На рис. 4.6.4 показан пример применения простой блок-схемы водной из компаний. Применены все пять типов элементов. Тем не менее схема выглядит вполне читаемой и понятной пользователю сотруднику компании. Рис. 4.6.3. Нотация Простая блок-схема» в MS Visio Глава 4. Описание бизнес-процессов организации 243 Нотация Простая блок-схема» часто подвергается в организациях различным вариациям: изменяется смысл элемента Решение (его используют в качестве операции процесса); по-разному используют стрелки связей (именуют или не именуют и т. п.); по-разному используют стрелки связей в сочетании с объектом «Документ»; прочее. — Интересно, что нотация Простая блок-схема» в томили ином виде часто используется специалистами по менеджменту качества при описании процессов СМК, так как она самая простая из из- вестных. Преимущества простой блок-схемы (с сокращенным до минимума количеством элементов): простота формирования графических схем процессов; — интуитивная понятность схем сотрудникам (даже без специального обучения); минимальная потребность в обучении сотрудников; — наличие доступных инструментов для описания процессов — (MS Visio, MS Однако, как это часто бывает на практике, если нотация используется без утвержденного внутреннего стандарта и специализированного средства моделирования, компания получает множество нестандартно оформленных схем, которые содержатся в различных файлах. Поддерживать такой массив информации в связном состоянии и отслеживать изменения сложно. Требуется большой объем ручного труда бизнес-аналитиков. Поэтому, выбирая нотацию Простая блок-схема», необходимо заранее разработать Рис. Пример схемы в нотации Простая блок схема На ча ло Дон ес ти решения до руководителей подразделений Изучить информацию в Б Д Кадры По дг от овить требования к персоналу икр уг обязанностей Подготовить распоряжение оп од боре кандидата среди персонала Руково д и те лис тру к ту р ны х подразделений Помощник директора пока драм Директор по общим вопросам Совет директоров ( С Д ) Решение С Д по кадровым вопросам Кор рек тиров ки требований и обязанностей Распоряжение и требования к кандидату Согласованные требования к кандидату Предложения пот р еб ов аниям к кандидату и обязанностям Информация о вакансиях Изм ен ен и я в штатном расписании Реш ен и е С Д о ротации кадров (т ак ти ческ ое решен и е) Р еш ен и е С Д он ов ы х вакансиях кадровая политика Кадровый резерв есть да да нет нет Ес ть корректировки Запросить предложения наз амеще- ни е вакантных должностей Направи ть предложения По дг от овить распоряжение оп ои ск е кандидата вне компании Направи ть предложения По дг от овить распоряжение опер ев оде на новую должность По дг от овить распоряжение оста жировке За прос Пре д ложения руководителей Рас пор яж ен и е оп ои ск е кандидата вне компании Информация обо тс ут ст вии кандидатов среди персонала Ка ндид ат ур ы для рассмотрения Запрос Ка ндид ат урана утверждение С Д Распоряжение на оформление кадровых вопросов (о переводе ) Распоряжение на оформление кадровых вопросов (о стажировке )Ка ндид ат согласен Ну жн ас тажи ров ка ? Ут ве р ди ть кандидатуру Ка ндид ат соответствует Есть новые кандидатуры да да да да да нет нет не т не т не т Ко не ц 246 Бизнес-процессы. Моделирование, внедрение, управление внутренний стандарт использования этой нотации; — внутренний стандарт формирования, хранения и актуализации файлов со схемами процессов. Масштабное использование в компании нотации Простая блок- схема без современного средства моделирования неэффективно. Нотация ARIS Нотация eEPC является частью общей методологии ARIS, в рамках которой организация рассматривается с четырех позиций организационной, функциональной, структуры данных и бизнес- процессов. При этом каждая из позиций разделяется натри подуровня описание требований, описание спецификации, описание внедрения. Для описания бизнес-процессов предлагается использовать около 80 типов моделей, каждая из которых принадлежит тому или иному аспекту eEPC — одна из первых нотаций, получившей широкую известность на российском рынке. Она относится к нотациям Work Flow. Особенности нотации — наличие элементов типа Событие и операторов логики И, неисключающее ИЛИ, исключающее «ИЛИ». В качестве примера рассмотрим процесс, представленный на рис. 4.6.5, который начинается с события Поступил заказ клиента. Оно инициирует операцию Выполнить учет заказав системе, которую проводит менеджер отдела сбыта. Для работы он использует систему учета заказов. Результат операции отображается событием Учет заказа выполнен. После этого менеджер по сбыту осуществляет операцию Выполнить анализ на соответствие номенклатуре. Ее результат — два альтернативных события Заказ соответствует номенклатуре и Заказ не соответствует номенклатуре. Процесс ветвится. Для отображения ветвления процесса используется символ логического исключающего ИЛИ ARIS — архитектура интегрированных информационных систем. ARIS eEPC (Extended Event-driven Process Chain) — расширенная модель цепочки процесса, управляемого событиями (нотация для описания бизнес-процессов). Глава 4. Описание бизнес-процессов организации 247 Операция Уведомить клиента о невозможности выполнения заказа может выполняться в двух случаях если заказ не соответствует номенклатуре или если производство невозможно. Для отображения на схеме процесса этих вариантов используется символ логического «ИЛИ». Нотация ARIS eEPC содержит большое количество графических элементов. Поэтому при выполнении проектов создаются так называемые методические фильтры (в рамках соглашений по моделированию, которые ограничивают количество типов элементов, доступных пользователям при создании схем процессов. (В некоторых средствах моделирования нотация ARIS eEPC сразу реализована с минимально необходимым набором элементов) Однако даже в этом случае неопытные пользователи создают схемы такой сложности, в которых трудно разобраться. К ним нужен подробный комментарий (либо наличие аналитика, способного объяснить схему). Почему возникает такой эффект Это результат описания множества возникающих при выполнении процесса ветвлений при помощи формальных логических операторов. Делать это приходится по строгим правилам. В результате появляется формально правильная, но громоздкая, плохо воспринимаемая схема. Впрочем, это проблема почти всех нотаций Work Flow. Для специалиста, который занимается моделированием постоянно, выбор ARIS eEPC в качестве инструмента описания вполне адекватен. Следует отметить, что типичная схема вне годится для автоматизации в системе класса BPM — (Business Process Management) (нужно применять дополнительный транслятор, переводящий ее в нотацию BPMN, с последующей ручной доработкой); сложна для восприятия рядовыми сотрудниками (их нужно учить правилам использования логических операторов и корректному чтению схем, которые их содержат Рис. 4.6.5. Схема процесса в нотации ARIS eEPC * ПЭО — планово-экономический отдел. Выполнить учет заказав системе Согласовать заявку с ПЭО Выполнить анализ на соответствие номенклатуре Поступил заказ клиента Заказ не соответствует номенклатуре Заказ соответствует номенклатуре Производство возможно Производство невозможно Cистема учета заказов Менеджер отдела сбыта Менеджер отдела сбыта Менеджер отдела сбыта Экономист ПЭО * Номенклатура изделий Номенклатура изделий Производствен- ные возможности Сопроводи- тельное письмо Заявка клиента Заявка клиента Заявка клиента Рассчитать цену, сумму и сроки выполнения заказа Согласовать условия поставки с клиентом Внести клиента в статистику неудовлетворенного спроса Уведомить клиента о невозможности выполнения заказа Условия выполнения заказа согласованы Условия выполнения заказа не согласованы Конец процесса Менеджер отдела сбыта Менеджер отдела сбыта Экономист ПЭО Cистема учета заказов Плановая калькуляция на заказ Заявка клиента Нормативы Файл Excel 250 Бизнес-процессы. Моделирование, внедрение, управление Итак, нотация ARIS eEPC не предназначена для описания автоматически исполняемых процессов и неудобна для восприятия из-за своей сложности. Моделирование вне дает значительных преимуществ ни для автоматизации, ни для регламентации. Это классическая, формально правильная, но неудобная для восприятия нотация. Несмотря на перечисленные проблемы, применение нотации ARIS eEPC и соответствующего средства моделирования, безусловно, позволяет создать в организации качественную, комплексную процессную модель. Многие крупные и средние российские компании используют для описания и регламентации бизнес-процессов. Могу предположить, что в этих компаниях постепенно произойдет переход от нотации ARIS eEPC к более сложной, но и более выразительной сточки зрения задач бизнес-моделирования) нотации BPMN 2.0. 4.6.4. Нотация BPMN |