Раздел 2. Бизнес-моделирование в разработке программ и в описании деятельности предприятия

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

Процесс разработки программ – жизненный цикл программного обеспечения.
Как и для любого промышленного изделия, жизненный цикл программного обеспечения (ЖЦПО) является моделью его создания и использования, отражающей его различные состояния, начиная с момента возникновения необходимости в данном изделии и заканчивая моментом его полного выхода из употребления.
Любое программное изделие проходит следующие этапы [1]:

• анализ требований;
• проектирование;
• кодирование (программирование);
• тестирование и отладка;
• эксплуатация и сопровождение.

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

Популярны три вида моделей ЖЦПО для программ разного масштаба и сложности

1. Каскадная модель (1970–1980 гг.) предполагает переход на следующий этап после полного окончания работ по предыдущему этапу.

2. Итерационная модель с промежуточным контролем (1980–1985 гг.) – циклы обратной связи между этапами дают возможность возврата и переделки работ на предыдущих этапах.

3. Спиральная эволюционная модель (1986–1990 гг.) – путем создания прототипов на этапах анализа требований, специфицирования и проектирования проверяется и обосновывается реализуемость принимаемых решений. Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии программного изделия. На нем уточняются цели и характеристики проекта, определяется его качество, планируются работы следующего витка с учетом анализа рисков.

Преимуществами спиральной модели являются:

1. накопление и повторное использование программных средств, моделей и прототипов;

2. ориентация на развитие и модификацию ПО в процессе его проектирования;

3. анализ риска и издержек в процессе проектирования.

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

1. Подход по модели водопада/каскадной модели – для не-больших, несложных, типовых задач.

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

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

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

Самыми сложными являются этапы анализа требований и постановки задачи, проектирования. Если ошибку, допущенную на этих этапах, не «отловить» сразу, ее должна обнаружить процедура тестирования. Но тогда стоимость в человеко-часах исправления этой ошибки будет в 10–30 раз выше. Если и тестирование не обнаружит такую ошибку, то проект может завершиться неудачей.
На этапе анализа требований нужно ответить на вопрос «Что должна делать будущая система?». В практике создания ПО [7] известно немало примеров неудачной реализации проекта именно из-за неполноты и нечеткости определения системных требований.
Список требований к разрабатываемой системе должен включать:

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

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

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

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

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

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

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

Как надо описывать бизнес-процессы? Выделять ли «сквозные процессы» или провести границы процессов по подразделениям? У последней позиции много сторонников среди менеджеров предприятий. Иногда все можно свести к смене терминологии, «измениться, не меняясь». Есть отдел закупок – будет процесс «Закупки», есть отдел сбыта – будет процесс «Продажи» и т. п., а начальники этих отделов и будут владельцами процессов. Кондратьев в «Семи нотах менеджмента» писал: «Раньше на складе хранили картошку, а теперь реализуют процесс хранения…».

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

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

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

1. Вертикальная декомпозиция – это деление на этапы или типы работ. Так, маркетинг мы разбиваем на изучение рынков, анализ продаж, построение прогноза продаж и т. п. Это часто называют функциональным делением, однако лучше воздержаться от этого термина, чтобы не вносить путаницу.

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

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

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

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

Бизнес-процесс – это логичный, последовательный, взаимосвязанный набор мероприятий, который потребляет ресурсы, создаёт ценность и выдаёт результат. В международном стандарте ISO 9000:2000 принят термин «процесс», однако в настоящее время эти термины можно считать синонимами.

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

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

Реинжиниринг бизнес-процессов (Business process reengineering) – это фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения максимальной эффективности производственно-хозяйственной и финансово-экономической деятельности, оформленное соответствующими организационно-распорядительными и нормативными документами. Бизнес-инжиниринг состоит из моделирования бизнес-процессов (разработка модели «как есть», её анализ, разработка модели «как надо») и разработки и реализации плана перехода к состоянию «как надо».

Основу многих современных методологий моделирования бизнес-процессов составили методология SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования), семейство стандартов IDEF (Icam DEFinition, где Icam – это Integrated Computer-Aided Manufacturing) и алгоритмические языки. Основные типы методологий моделирования и анализа бизнес-процессов:

• Моделирование бизнес-процессов (Business Process Modeling). Наиболее широко используемая методология описания бизнес-процессов – стандарт IDEF0. Модели в нотации IDEF0 предназначены для высокоуровневого описания бизнеса компании в функциональном аспекте.

• Описание потоков работ (Work Flow Modeling). Стандарт IDEF3 предназначен для описания рабочих процессов и близок к алгоритмическим методам построения блок-схем.

• Описание потоков данных (Data Flow Modeling). Нотация DFD (Data Flow Diagramming) позволяет отразить последовательность работ, выполняемых по ходу процесса, и потоки информации, циркулирующие между этими работами.

• Прочие методологии.

По отношению к получению добавленной ценности продукта или услуги можно выделить следующие классы процессов:

• Основные бизнес-процессы (например, маркетинг, производство, поставки и сервисное обслуживание продукции).

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

• Бизнес-процессы управления.

Бизнес-модель – это формализованное (графическое, табличное, текстовое, символьное) описание бизнес-процессов. Основная область применения бизнес-моделей – это реинжиниринг бизнес-процессов.

Цели моделирования бизнес-процессов обычно формулируются следующим образом:

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

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

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

Этапы описания бизнес-процессов:

• определение целей описания;
• описание окружения, определение входов и выходов бизнес-процесса, построение IDEF0-диаграмм;
• описание функциональной структуры (действия процесса), построение IDEF3-диаграмм;
• описание потоков (материальных, информационных, финансовых) процесса, построение DFD-диаграмм;
• построение организационной структуры процесса (отделы, участники, ответственные).

IDEF0
Модель состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы – главные компоненты модели, все функции и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса:

• Управляющая информация входит в блок сверху.
• Входная информация входит в блок слева.
• Результаты выходят из блока справа.
• Механизм (человек или автоматизированная система), который осуществляет операцию, входит в блок снизу.

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

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

На таких диаграммах не указаны явно ни последовательность, ни время. Метод обладает рядом недостатков: сложность восприятия (большое количество дуг на диаграммах и большое количество уровней декомпозиции), трудность увязки нескольких процессов.

IDEF3
Этот метод предназначен для моделирования последовательности выполнения действий и взаимозависимости между ними в рамках процессов. Модели IDEF3 могут использоваться для детализации функциональных блоков IDEF0, не имеющих диаграмм декомпозиции.

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

Типы связей IDEF3:
• Временное предшествование (Temporal precedence), простая стрелка. Исходное действие должно завершиться, прежде чем конечное действие сможет начаться.
• Объектный поток (Object flow), стрелка с двойным нако-нечником. Выход исходного действия является входом конечного действия. Исходное действие должно завершиться, прежде чем конечное действие сможет начаться. Наименования потоковых связей должны чётко идентифицировать объект, который передается с их помощью.
• Нечеткое отношение (Relationship), пунктирная стрелка.
Завершение одного действия может инициировать начало выполнения сразу нескольких других действий, или наоборот, определенное действие может требовать завершения нескольких других действий до начала своего выполнения (ветвление процесса). Ветвление процесса отражается с помощью специальных блоков:
• «И», блок со знаком &.
• «Исключающее ИЛИ» («одно из»), блок со знаком Х.
• «ИЛИ», блок со знаком О.
Если действия «И», «ИЛИ» должны выполняться синхронно, это обозначается двумя двойными вертикальными линиями внутри блока, асинхронно – одной.
Метод IDEF3 позволяет декомпозировать действие несколько раз, что обеспечивает документирование альтернативных потоков процесса в одной модели.

DFD
Цель такого представления – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные. Может отражать не только информационные, но и материальные потоки.
Так же как и в других моделях поддерживается декомпозиция.

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

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

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

При моделировании бизнес-процессов диаграммы потоков данных (DFD) используются для построения моделей «AS-IS» и «AS-TO-BE», отражая, таким образом, существующую и предлагаемую структуру бизнес-процессов организации.

ARIS
В настоящее время наблюдается тенденция интеграции разнообразных методов моделирования, проявляющаяся в форме создания интегрированных средств моделирования. Одним из таких средств является программный продукт, носящий название ARIS (Architecture of Integrated Information Systems), разработанный германской фирмой IDS Scheer.

ARIS поддерживает четыре типа моделей (и множество видов моделей в каждом типе), отражающих различные аспекты исследуемой системы:
• организационные модели, представляющие структуру системы – иерархию организационных подразделений, должностей и конкретных лиц, связи между ними, а также территориальную привязку структурных подразделений;
• функциональные модели, содержащие иерархию целей, стоящих перед аппаратом управления, с совокупностью деревьев функций, необходимых для достижения поставленных целей;
• информационные модели, отражающие структуру информации, необходимой для реализации всей совокупности функций системы;
• модели управления, представляющие комплексный взгляд на реализацию бизнес-процессов в рамках системы.

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

Основная бизнес-модель ARIS – eEPC (extended Event-driven Process Chain, расширенная модель цепочки процессов, управляемых событиями). Нотация ARIS eEPC является расширением нотации IDEF3. Бизнес-процесс в нотации eEPC представляет собой поток последовательно выполняемых работ (процедур, функций), расположенных в порядке их выполнения. Реальная длительность выполнения процедур в eEPC визуально не отражается. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например, MS Project.

Модели в ARIS представляют собой диаграммы, элементами которых являются разнообразные объекты – «функции», «события», «структурные подразделения», «документы» и т.д. Между объектами определённых видов могут быть установлены связи определённых видов («выполняет», «принимает решение», «должен быть проинформирован о результатах» и т.д.). Каждому объекту соответствует определенный набор атрибутов, которые позволяют ввести дополнительную информацию о конкретном объекте.

Основные объекты нотации eEPC следующие.
• Функция. Служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия. Каждая функция должна быть инициирована событием и должна завершаться событием; в каждую функцию не может входить более одной стрелки, «запускающей» выполнение функции, и выходить более одной стрелки, описывающей завершение выполнения функции.
• Событие. Служит для описания реальных событий, воздействующих на выполнение функций.
• Организационная единица. Например, управление или отдел.
• Документ. Отражает реальные носители информации, на-пример, бумажные документы.
• Прикладная система.
• Кластер информации. Характеризует набор сущностей и связей между ними.
• Связь между объектами. Тип отношений между объектами, например, активация выполнения функции некоторым событием.
• Логический оператор. Операторы «И», «ИЛИ» или исключающее «ИЛИ» позволяют описать ветвление процесса.

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

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

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