В любой организации функционирует множество взаимосвязанных процессов. Одни обеспечивают создание и предоставление продуктов и услуг, другие связаны с управлением, развитием, взаимодействием с клиентами или обеспечением деятельности. При формировании процессной архитектуры возникает необходимость определить состав этих процессов, систематизировать их и установить границы между ними.
На практике такая работа нередко начинается с формирования собственного перечня процессов. Аналитики изучают деятельность организации, выделяют функциональные области, определяют группы процессов и постепенно формируют классификационную структуру. При этом значительная часть решаемых задач имеет общий характер и не зависит от отрасли, масштаба или организационной структуры предприятия.
Возникает закономерный вопрос: обязательно ли каждый раз начинать классификацию процессов с нуля?
Существуют готовые инструменты, позволяющие использовать ранее систематизированные представления об организационной деятельности. Наиболее известный среди них — APQC Process Classification Framework (PCF). Однако наличие универсальной классификации еще не означает, что ее удобно использовать в любом практическом контексте.
Sophia представляет собой авторскую трехуровневую классификационную модель процессов коммерческой организации, предназначенную для использования при формировании и изменении процессной архитектуры.
Модель систематизирует процессы по содержанию и назначению деятельности, определяет их цели, основные входы и выходы, но не устанавливает конкретные способы выполнения, организационную ответственность или обязательную последовательность действий.
В этой статье я хочу рассмотреть предпосылки создания Sophia, ее методологическую основу, архитектуру, результаты практического применения и проведенных проверок, а также ограничения, которые необходимо учитывать при работе с этой моделью.
Предпосылки создания Sophia
Идея разработки Sophia возникла у меня из наблюдений, накопленных в ходе профессиональной деятельности.
В русскоязычном сегменте моей профессиональной практики, охватывающем порядка двух десятков организаций разных отраслей и масштабов, я ни разу не сталкивался с использованием APQC PCF при формировании процессной архитектуры. Более того, специалисты, участвовавшие в соответствующих работах, зачастую не знали о существовании этой классификации.
Вместо обращения к существующему инструментарию каждый раз формировалась собственная структура процессов, нередко начиная с определения наиболее общих функциональных областей организации.
Разумеется, такое наблюдение не позволяет делать выводы о распространенности APQC PCF в целом. Мой личный профессиональный опыт не является репрезентативным исследованием практики процессного управления, однако он позволяет обозначить проблему, неоднократно возникавшую в конкретных проектах: отсутствие использования готовой классификационной основы приводило к повторному выполнению сходной аналитической работы.
Второй предпосылкой стала сложность самого инструментария.
APQC PCF представляет собой развитую многоуровневую классификацию с большим количеством элементов и подробной функциональной декомпозицией. Ее применение предполагает понимание предмета классификации, логики выделения элементов, различий между функциональными назначениями и способами реализации деятельности.
По моей оценке, для специалиста без достаточно серьезной методологической подготовки работа с такой моделью может представлять значительную сложность. В отдельных случаях это относится даже к аналитикам, уже имеющим практический опыт работы с бизнес-процессами.
При этом проблема заключается не в самом существовании подробной классификации. Развитая детализация имеет самостоятельную ценность, особенно при решении задач, требующих сопоставления большого количества конкретных видов деятельности.
Вопрос состоял в другом: можно ли сформировать более компактную классификационную модель, достаточную для систематизации процессов коммерческой организации на обобщенном уровне, не воспроизводя всю глубину существующего инструментария?
Так у меня возник замысел Sophia.
Разработка продолжалась почти два года. За это время модель неоднократно пересматривалась и уточнялась, а ее предшествующие редакции применялись при решении реальных задач формирования и изменения процессной архитектуры.
В основу разработки было положено стремление сохранить содержательную определенность классификационных элементов при ограниченной глубине универсальной декомпозиции.
Простота освоения и практического использования выступала одним из исходных проектных ориентиров, однако я пока не берусь судить, что это является доказанным преимуществом Sophia перед другими моделями без самостоятельного сравнительного исследования.
Универсальная классификация и процессная архитектура организации
Прежде чем рассматривать устройство Sophia, необходимо разграничить несколько понятий, которые нередко смешиваются при работе с процессами.
Классификация процессов представляет собой систему группировки процессов по определенным признакам. В зависимости от принятого подхода такими признаками могут выступать назначение деятельности, ее содержание, характер создаваемых результатов или другие существенные характеристики.
Классификация устанавливает общую структуру, в рамках которой могут быть представлены различные виды организационной деятельности.
Процессная архитектура конкретной организации отражает состав, группировку и взаимосвязи процессов, относящихся непосредственно к деятельности этой организации. Ее содержание определяется бизнес-моделью, продуктами и услугами, организационными особенностями, требованиями и другими условиями.
Наконец, описание отдельного бизнес-процесса предполагает более подробное рассмотрение его границ, результатов, участников, последовательности действий, условий выполнения и взаимодействия с другими процессами.
Это разные объекты аналитической работы.
Универсальная классификация может служить основой для формирования процессной архитектуры, но сама по себе такой архитектурой не является. Тем более она не заменяет описание и моделирование конкретных процессов.
Например, в универсальной классификации может присутствовать процесс, связанный с управлением запасами. Однако способ организации соответствующей деятельности будет различаться у производственного предприятия, розничного продавца и компании, оказывающей услуги с использованием расходных материалов.
В одном случае управление запасами может быть связано с несколькими самостоятельными процессами, распределенными между различными участниками, в другом соответствующая деятельность может составлять лишь часть более крупного процесса.
Универсальная модель не должна заранее определять, какое организационное решение является правильным.
Элемент классификации не равен процессу организации
Одно из основных допущений Sophia состоит в отсутствии обязательного взаимно однозначного соответствия между элементами классификации и процессами конкретного предприятия. Один процесс Sophia может реализовываться через несколько процессов организации. И наоборот, один фактический процесс может обеспечивать результаты, относящиеся к нескольким элементам классификации.
Отсюда следует важное практическое ограничение: количество элементов Sophia не определяет необходимое или оптимальное количество процессов конкретной организации. Нельзя взять все элементы классификации, перенести их в реестр процессов предприятия и считать полученную структуру полноценной процессной архитектурой. Точно так же отсутствие в организации процесса с названием, совпадающим с элементом Sophia, не свидетельствует о том, что соответствующая деятельность не выполняется.
Содержательное соответствие определяется через назначение деятельности, ее цели и результаты, а не только через сходство наименований.
Для чего тогда необходима универсальная модель?
Основное назначение универсальной классификации заключается в предоставлении общей системы ориентиров, позволяющей систематизировать существующую или проектируемую деятельность. Такая основа помогает аналитику последовательно рассматривать различные функциональные области организации, устанавливать содержательные соответствия и обнаруживать вопросы, требующие дополнительного исследования.
При этом классификация не определяет автоматически ни состав необходимых процессов, ни их границы, ни качество выполнения деятельности.
Sophia исходит из того, что окончательные аналитические решения всегда должны приниматься на основании сведений о конкретной организации.
Методологические ориентиры Sophia
Sophia использует существующий понятийный аппарат процессного подхода и управления бизнес-процессами. При ее разработке учитывались классификационные и методологические подходы, представленные в APQC PCF, BABOK и BPM CBOK.
APQC Process Classification Framework
APQC PCF представляет собой иерархическую классификацию процессов, предназначенную для систематизации деятельности организаций и создания общей основы для сопоставления процессов и их показателей.
Эта классификация развивается с начала 1990-х годов и используется, в частности, в задачах процессного управления, определения процессов и бенчмаркинга.
Межотраслевая редакция PCF 8.0 содержит пять уровней классификационной иерархии: категории, группы процессов, процессы, активности и задачи. Такая структура позволяет последовательно переходить от наиболее общих функциональных областей к более детализированным элементам деятельности.
В Sophia используется трехуровневая структура:
- категория процессов
- группа процессов
- процесс
Эти уровни терминологически соотносятся с первыми тремя уровнями APQC PCF, однако их состав и содержание определяются собственной архитектурой Sophia.
Ограничение глубины классификации является моим принципиальным проектным решением. Sophia не предусматривает универсального описания активности и отдельных задач, оставляя дальнейшую детализацию на уровне конкретной организации.
BABOK и BPM CBOK
A Guide to the Business Analysis Body of Knowledge (BABOK Guide) представляет собой свод знаний по бизнес-анализу, разработанный International Institute of Business Analysis (IIBA). Он систематизирует области знаний, задачи, техники и компетенции, необходимые для профессиональной деятельности бизнес-аналитика.
BABOK не является универсальной классификацией процессов организации, его предметом выступает прежде всего деятельность по бизнес-анализу, включая исследование потребностей, анализ изменений и работу с требованиями.
Guide to the Business Process Management Common Body of Knowledge (BPM CBOK), разрабатываемый ABPMP International, охватывает профессиональные знания и практики управления бизнес-процессами. В его предметную область входят моделирование, анализ, проектирование, измерение результативности, трансформация и управление процессами.
BPM CBOK предоставляет методологические ориентиры для работы с бизнес-процессами, но не предназначен для воспроизведения универсального состава процессов любой коммерческой организации.
Sophia не заменяет эти источники, а использует общепринятую терминологию и отдельные архитектурные принципы, при этом она обладает собственным составом элементов, логикой группировки и правилами описания процессов.
Архитектура и принципы построения Sophia 1.3
В текущей редакции Sophia 1.3 содержится 8 категорий процессов, 54 группы процессов и 272 процесса.
Все элементы образуют иерархическую структуру, в которой каждый процесс относится к определенной группе, а каждая группа принадлежит одной из категорий.
Три уровня классификации
На верхнем уровне L1 расположены категории процессов. Они представляют собой наиболее крупные области классификации, объединяющие группы по общему направлению деятельности.
Уровень L2 образуют группы процессов, объединенные общим назначением или предметом деятельности.
На уровне L3 располагаются собственно процессы Sophia. Каждый элемент представляет обобщенное описание процесса коммерческой организации с указанием его назначения, цели, основных входов и выходов.
Структура текущей версии представлена следующими категориями:
| Категория процессов L1 | Группы L2 | Процессы L3 |
|---|---|---|
| Стратегическое управление | 6 | 33 |
| Управление развитием | 7 | 28 |
| Управление продуктами и услугами | 6 | 23 |
| Коммерческая деятельность | 6 | 23 |
| Операционная деятельность | 10 | 54 |
| Управление клиентскими отношениями | 6 | 30 |
| Поддерживающие функции | 8 | 51 |
| Корпоративное управление | 5 | 30 |
| Итого | 54 | 272 |
Здесь мне сразу следует обозначить, что такое распределение отражает функциональную логику модели, а не предполагаемую организационную структуру предприятия.
Например, наличие категории «Корпоративное управление» не означает необходимости создания одноименного подразделения. Аналогично категория «Управление клиентскими отношениями» не закрепляет соответствующие процессы за единой организационной единицей.
Границы подразделений, распределение ответственности и полномочий определяются самостоятельно при проектировании организации деятельности.
Содержание карточки процесса
Каждый процесс L3 описывается посредством установленного набора атрибутов:
- код и наименование
- категория и группа процессов
- тип процесса
- описание
- цель
- основные входы и выходы
Описание раскрывает содержание деятельности на обобщенном уровне. Цель определяет ее назначение, а входы и выходы позволяют установить, какие сведения, ресурсы или результаты используются и формируются.
Тип процесса выступает дополнительной классификационной характеристикой. В Sophia мной используются значения «управление», «развитие», «создание ценности» и «поддерживающий».
Особое значение имеет совместное рассмотрение атрибутов. Совпадение или сходство наименований еще не означает тождественности процессов, как и различие названий не исключает содержательного соответствия.
Давайте рассмотрим несколько примеров.
В категории «Управление клиентскими отношениями» процесс 6.3.3 «Обработка обращений и инцидентов» предусматривает рассмотрение зарегистрированных обращений, определение необходимых действий, получение результатов от исполнителей, формирование ответа клиенту и фиксацию итогов обработки.
При этом процесс 6.2.1 «Оказание сервисной поддержки клиентам» связан непосредственно с предоставлением поддержки при использовании продуктов и услуг, включая выполнение необходимых действий по устранению возникающих затруднений.
Оба процесса относятся к работе с клиентами, но имеют различное назначение: обработка обращения и выполнение сервисных действий не являются полностью тождественными видами деятельности.
Другой пример связан с обеспечением материальными ресурсами.
Процесс 5.2.3 «Пополнение запасов» относится к операционной деятельности и предусматривает организацию пополнения запасов до требуемого уровня в соответствии с потребностями и установленными нормативами.
Процесс 7.6.3 «Проведение закупок», напротив, относится к поддерживающим функциям и охватывает закупочные процедуры, включая выбор поставщиков, оформление договорных отношений и размещение заказов.
Пополнение запасов и проведение закупок могут быть функционально связаны, но их назначение не совпадает. Организации может требоваться пополнение запасов, осуществляемое посредством закупки, внутреннего перераспределения или другого механизма обеспечения.
Границы элементов и функциональные взаимосвязи
Sophia не предполагает, что процессы существуют изолированно друг от друга. Напротив, достижение результата может зависеть от нескольких элементов классификации, относящихся к разным группам и категориям.
Например, выполнение клиентского обязательства может требовать взаимодействия коммерческой, операционной, финансовой и договорной деятельности. Наличие подобных взаимосвязей само по себе не свидетельствует о дублировании элементов или нарушении классификационной структуры.
При этом важно различать функциональную связь и последовательность выполнения работ. Входы и выходы процессов Sophia позволяют исследовать потенциальные зависимости, но не образуют готовую модель взаимодействия процессов конкретной организации.
Иерархическая нумерация также не устанавливает порядок выполнения деятельности. Код используется для идентификации и классификации элемента, а не для определения его места во временной последовательности.
Практическое применение Sophia
Sophia предназначена для использования в качестве классификационной основы при формировании и изменении процессной архитектуры коммерческой организации. Документация модели предусматривает два основных сценария применения, различающихся прежде всего исходными условиями аналитической работы.
Формирование или изменение процессной архитектуры существующей деятельности
Первый сценарий предполагает, что организация уже осуществляет определенную деятельность, а аналитик располагает результатами ее предварительного исследования.
Исходные сведения могут включать перечень выявленных процессов, их назначение, результаты, входы, выходы и существующие взаимосвязи.
Sophia используется для сопоставления этой деятельности с элементами универсальной классификации, при этом сопоставление выполняется по содержанию и назначению, а не по буквальному совпадению наименований. Если отдельному элементу Sophia не находится соответствия среди выявленных процессов организации, это становится основанием для дополнительного исследования.
Однако отсутствие соответствия не является доказательством отсутствия деятельности или наличия организационной проблемы. Необходимо установить, применим ли рассматриваемый элемент к организации, не выполняется ли соответствующая деятельность в составе другого процесса и достаточно ли исходных сведений для обоснованного заключения.
По результатам исследования аналитик определяет состав, группировку, границы и необходимую глубину декомпозиции процессов организации.
Формирование процессной архитектуры проектируемой деятельности
Второй сценарий предназначен для ситуаций, когда деятельность еще не организована или предполагается формирование нового направления.
Исходными данными выступают цели организации, бизнес-модель, предполагаемые продукты и услуги, требования и ограничения.
Аналитик рассматривает классификацию Sophia, определяет потенциально применимые элементы и использует их как содержательные ориентиры при проектировании состава процессов. На основании этого формируется процессная архитектура предполагаемой деятельности. Такой сценарий применим не только при создании новой организации, но и при расширении деятельности существующего предприятия.
И здесь сохраняется то же принципиальное ограничение: наличие процесса в Sophia не означает обязательной необходимости его включения в проектную архитектуру.
Опыт практической апробации
В ходе разработки Sophia ее предшествующие редакции применялись мной при выполнении реальных аналитических и проектных работ. Использовавшиеся редакции были архитектурно и содержательно близки к опубликованной версии 1.3.
Ниже представлены три случая такого применения. Описание намеренно ограничено уровнем, необходимым для раскрытия характера выполненной работы и результатов, без раскрытия конфиденциальных сведений об организациях.
Проектирование процессов интернет-магазина потребительских товаров.
В первом рассматриваемом случае задача заключалась в формировании процессной архитектуры создаваемого бизнеса.
Прототип Sophia использовался как классификационная основа для определения предполагаемого состава процессов. На основании сформированной архитектуры были подробно разработаны конкретные процессы организации, после чего они были реализованы.
Результатом проекта стал запуск интернет-магазина с функционирующими процессами.
Этот случай продемонстрировал мне практическую пригодность использовавшейся редакции Sophia в качестве основы для проектирования процессной архитектуры с нуля. При этом сам запуск бизнеса был результатом комплекса организационных и проектных работ, а не непосредственным результатом применения классификационной модели.
Анализ процессной архитектуры международного медийного агентства.
Во втором рассматриваемом случае Sophia применялась при верхнеуровневом исследовании уже действующей организации.
Сопоставление существующей процессной архитектуры с классификационными ориентирами позволило мне выявить процессы, отсутствовавшие в исследованной организации. Полученные результаты были переданы другой команде для дальнейшей проработки, и последующие работы позволили устранить выявленные пробелы.
В этом случае практическая ценность классификации проявилась в возможности использовать ее как опорную структуру для анализа состава существующей процессной архитектуры. При этом выявление отсутствующих процессов являлось результатом аналитической работы с использованием Sophia, а не автоматическим свойством самой модели.
Формирование процессов при расширении деятельности производственной организации.
Третий рассматриваемый случай был связан с организацией нового направления деятельности на предприятии, ранее занимавшемся физическим производством товаров.
Новое направление предполагало оказание услуг, вследствие чего существующая система процессов требовала дополнения. Sophia использовалась мной для определения процессов, необходимых для организации новой деятельности, но отсутствовавших в действующей процессной архитектуре. В дальнейшем соответствующие процессы были подробно разработаны и внедрены.
Этот пример показал мне возможность применения универсальной классификации не только для создания архитектуры с нуля или анализа существующей структуры, но и для ее развития в условиях изменения бизнес-модели.
Методологическая проверка Sophia
Практическое применение мной предшествующих редакций сопровождалось последовательным развитием и уточнением содержания модели. На заключительных этапах разработки я провел дополнительные методологические проверки, направленные на оценку структуры, содержательных границ и способности Sophia представлять различные виды деятельности коммерческих организаций.
Структура и внутренняя согласованность
Одно из направлений проверки было связано с анализом классификационной иерархии, содержания карточек процессов, функциональных взаимосвязей и потенциальных пересечений между элементами. Я проверял не только формальные характеристики структуры, но и содержательное различие процессов.
Например, наличие нескольких процессов, связанных с управлением определенным объектом, еще не означает избыточного дублирования. Необходимо установить, различаются ли их назначение, результаты или контекст деятельности. Аналогично отсутствие прямой связи между двумя элементами не является самостоятельным доказательством функционального пробела.
Сопоставление с APQC PCF
Отдельное направление моей проверки представляло собой архитектурно-функциональное сопоставление Sophia с межотраслевой классификацией APQC PCF 8.0.
Я проводил это сравнение по содержанию и назначению деятельности с учетом различий в уровне детализации.
При этом отсутствие в Sophia самостоятельного элемента с определенным названием не рассматривалось как достаточное основание для признания функционального пробела. Я проверял возможность представления соответствующей деятельности посредством более общего назначения или сочетания нескольких элементов классификации. Аналогичный принцип использовался мной при обратном сопоставлении элементов Sophia с APQC PCF.
Организационные кейсы и функциональные сценарии
Заключительная проверка включала в себя 14 синтетических организационных кейсов и 50 функциональных сценариев, представлявших различные условия деятельности коммерческих организаций. В общей сложности мной проверялись 158 необходимых результатов: 58 в составе организационных кейсов и 100 в составе функциональных сценариев.
Дополнительно я провел обратный просмотр всех 272 процессов Sophia, а также 54 групп и 8 категорий классификации.
Границы применимости и условия использования
Универсальность Sophia определяется ее назначением как общей классификационной основы, но не означает безусловной применимости ко всем организациям и видам деятельности.
В документации модели я прямо устанавливаю следующую границу:
Sophia применима только к коммерческим организациям в полной мере. Бюджетные учреждения и некоммерческие организации также могут использовать ее целиком или по частям, но применимость не гарантируется.
Это ограничение связано с предметом классификации и принятыми при ее разработке методологическими допущениями. Даже применительно к коммерческим организациям Sophia не предполагает обязательного наличия каждого классификационного элемента. Состав и границы фактических или проектируемых процессов зависят от характера деятельности, масштаба организации, применимых требований и других условий.
Кроме того, Sophia не является:
- описанием фактических процессов конкретной организации
- организационной моделью или схемой распределения ответственности
- готовой последовательностью выполнения процессов
- нормативным документом
- инструментом непосредственной оценки результативности, эффективности или зрелости процессов
- набором универсальных управленческих решений
Эта классификация может использоваться как основа соответствующей аналитической работы, но не заменяет собой исследование деятельности, определение критериев оценки, моделирование процессов или обоснование проектных решений.
Отсутствие отраслевой детализации также является моим осознанным ограничением модели.
Доступность и лицензирование
Sophia является моей авторской разработкой и распространяется бесплатно с сохранением исключительных прав правообладателя.
Эта модель доступна для свободного изучения и практического применения, включая использование в коммерческой деятельности организаций и при оказании профессиональных консультационных услуг в пределах лицензионных условий. При этом разрешенное коммерческое применение не означает предоставления права на перепродажу, самостоятельное коммерческое распространение или перераспространение переработанных версий модели.
Использование охраняемых материалов Sophia в образовательных продуктах и программах, включая курсы, тренинги и учебные пособия, требует моего отдельного разрешения независимо от коммерческого или некоммерческого характера такого использования.
Актуальная редакция модели и сопутствующие материалы представлены на официальной странице Sophia.
Полные условия использования приведены в лицензионном соглашении.
Заключение. Место Sophia в работе с процессной архитектурой
Формирование процессной архитектуры требует исследования деятельности организации, определения состава процессов, их назначения, границ и взаимосвязей.
Очевидно, что универсальная классификационная модель не может выполнить эту работу вместо аналитика, поскольку не располагает сведениями о конкретной организации и не определяет автоматически, какие процессы необходимы для достижения ее целей. Однако такая модель может предоставить систематизированную основу, позволяющую не начинать классификацию деятельности с полностью самостоятельного формирования всех функциональных областей и групп процессов.
Именно эту задачу призвана решать Sophia.
Ее трехуровневая структура ориентирована на представление процессов коммерческой организации на обобщенном уровне, без обязательной детализации до отдельных операций и задач.
Практическое применение предшествующих редакций продемонстрировало мне возможность использования такой основы при создании новой процессной архитектуры, исследовании существующей и проектировании процессов для новых направлений деятельности, а последующие методологические проверки позволили дополнительно исследовать внутреннюю структуру и функциональные границы модели.
При этом Sophia не претендует на роль универсального решения всех задач процессного управления.
Ее назначение более конкретное: предоставить классификационную основу для формирования и изменения процессной архитектуры коммерческой организации, сохраняя самостоятельность аналитических и проектных решений. Именно в этих границах и следует рассматривать ее возможности, результаты применения и направления дальнейшего развития.
