Главная » Красота и Здоровье » Процессный подход к управлению ИТ. Эталонные модели. Эталонная модель компетентностей педагогического работника Идеальная эталонная модель в которой представлены основные

Процессный подход к управлению ИТ. Эталонные модели. Эталонная модель компетентностей педагогического работника Идеальная эталонная модель в которой представлены основные

Предлагаемая эталонная модель BPM (Business Process Management) основывается на цепочке следующих предпосылок:

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

BPM (как дисциплина) предлагает системный подход к реализации процессного управления;

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

Гибкость BPM-системы предприятия является основным фактором ее успеха;

Специализированная программная платформа (BPM suite) для реализации BPM-системы предприятия необходима, но недостаточна, так как BPM занимает особое место в архитектуре предприятия.

Цель: повышение производительности предприятия

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

Измерение хода исполнения производственно-хозяйственной деятельности (обычно такие измерения представлены в форме различных метрик или индикаторов, например, процент возвращающихся клиентов);

Вычленение из внешней бизнес-экосистемы важных для предприятия событий (например, законов или новых потребностей рынка);

Определение стратегии развития бизнеса предприятия;

Реализация принятых решений (путем внесения изменений в бизнес-систему предприятия).

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

Обеспечение руководства надлежащей информацией и инструментами для принятия решения;

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

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

Процессное управление

Мир бизнеса давно понял (см. такие методики, как TQM, BPR, Six Sigma, Lean, ISO 9000, и др.), что службы и процессы - это основа функционирования большинства предприятий. Множество предприятий используют процессное управление для организации своей производственно-хозяйственной деятельности, как портфолио бизнес-процессов и методов управления ими.

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

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

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

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

Что моделируете, то и выполняете

На рис. 2 приведена обобщенная модель процессно-управляемого предприятия.

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

Такое описание - основа дисциплины BPM, позволяющей моделировать, автоматизировать, выполнять, контролировать, измерять и оптимизировать потоки работ, охватывающие программные системы, сотрудников, клиентов и партнеров в пределах и вне границ предприятия. Дисциплина BPM рассматривает все операции с бизнес-процессами (моделирование, исполнение и т.п.) как единое целое (рис. 3).

На данный момент в индустрии BPM еще не сложилась надлежащая система стандартов на форматы формального описания бизнес-процессов. Три наиболее популярных формата: BPMN (Business Process Modelling Notation , графическое представление моделей бизнес-процессов), BPEL (Business Process Execution Language , формализация исполнения взаимодействия между Web-сервисами) и XPDL (XML Process Description Language, www.wfmc.org, спецификация по обмену моделями бизнес-процессов между различными приложениями) были разработаны различными группами и для различных целей и, к сожалению, адекватно не взаимодополняют друг друга.

Ситуация усугубляется тем, что за различными форматами стоят различные производители и каждый старается «протолкнуть» на рынок свое решение. Как это неоднократно повторялось, в подобной борьбе интересы конечного потребителя мало принимаются во внимание - сегодня нет достаточно мощной организации, представляющей интересы конечного потребителя BPM (по аналогии с группой стандартов для HTML , успех которой объясняется принятием всеми разработчиками Web-браузеров единого теста ACID3 для сравнения своих продуктов). Идеальной ситуацией в BPM было бы стандартное определение семантики исполнения для BPMN-подобного описания бизнес-процессов. Именно стандартная семантика исполнения гарантировала бы одинаковую интерпретацию бизнес-процессов любым ПО. Дополнительно такое описание должно позволять адаптацию степени описания бизнес-процессов для нужд конкретного потребителя (например, пользователь видит грубую диаграмму, аналитик - более подробную и т.п.).

Все это не означает, что BPEL или XPDL станут ненужными - их использование будет скрыто, как это происходит в сфере подготовки электронных документов. Один и тот же электронный документ может одновременно существовать в XML, PDF, PostScript и т.п., но только один основной формат (XML) используется для модификации документа.

Дисциплина BPM в культуре предприятия

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

события (events) - явления, происшедшие в пределах и вне границ предприятия, на которые возможна некая реакция бизнес-системы, например, при получении заказа от клиента необходимо начать бизнес-процесс обслуживания;

объекты (data and documents objects) - формальные информационные описания реальных вещей и людей, образующих бизнес; это информация на входе и выходе бизнес-процесса, например, бизнес-процесс обслуживания заказа получает на входе собственно формуляр заказа и информацию о клиенте, а на выходе формирует отчет о выполнении заказа;

деятельности (activities) - мелкие работы, преобразующие объекты, например автоматические деятельности типа проверки кредитной карты клиента или деятельности, осуществляемые человеком, такие как визирование документа руководством;

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

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

аудиторские следы (audit trails) - информация о выполнении конкретного бизнес-процесса, например, кто сделал, что и с каким результатом;

основные индикаторы производительности (Key Performance Indicator, KPI) - ограниченное число показателей, измеряющих степень достижения поставленных целей.

Рис. 4 иллюстрирует распределение артефактов между различными частями бизнес-системы предприятия. Выражение «процессы (как шаблоны)» означает абстрактные описания (модели или планы) процессов;

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

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

BPM-система, как правило, не идеальна (например, некоторые процессы могут существовать лишь на бумаге, а некоторые детали «живут» только в умах определенных людей), но она существует. Например, любую реализацию ISO 9000 можно рассматривать как пример BPM-системы.

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

Специализированное ПО для реализации BPM-систем

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

Инструмент моделирования (Process modelling tool) - графическая программа для манипулирования такими артефактами, как события, правила, процессы, активности, службы и т.д.;

Инструмент тестирования (Process testing tool) - среда функционального тестирования, которое позволяет «исполнять» процесс по различным сценариям;

Хранилище шаблонов (Process template repository) - база данных шаблонов бизнес-процессов с поддержкой различных версий одного и того же шаблона;

Исполнитель процессов (Process execution engine);

Хранилище экземпляров (Process instance repository) - база данных для выполняемых и уже выполненных экземпляров бизнес-процессов;

Список работ (Work list) - интерфейс между BPM suite и пользователем, выполняющим некоторые активности в рамках одного или нескольких бизнес-процессов;

Приборная панель (Dashboard) - интерфейс оперативного контроля за исполнением бизнес-процессов;

Инструмент анализа (Process analysis tool) - среда для изучения тенденции исполнения бизнес-процессов;

Инструмент имитационного моделирования (Process simulation tool) - среда для тестирования производительности бизнес-процессов.

Необходимость взаимодействия между BPM suite и корпоративным ПО, которое поддерживает другие артефакты, вызвала появление нового класса корпоративного ПО - Business Process Platform (BPP). Типичные технологии BPP (рис. 6):

Business Event Management (BEM) - анализ бизнес-событий в режиме реального времени и запуск соответствующих бизнес-процессов (BEM связан с Complex Event Processing (CEP) и Event Driven Architecture (EDA));

Business Rules Management (BRM) - явное и формальное кодирование бизнес-правил, которые могут модифицироваться пользователями;

Master Data Management (MDM) - упрощение работы со структурированными данными за счет устранения хаоса при использовании одних и тех же данных;

Enterprise Content Management (ECM) - управление корпоративной информацией, предназначенной для человека (обобщение понятия документ);

Configuration Management Data Base (CMDB) - централизованное описание всей информационно-вычислительной среды предприятия, используемое для привязки BPM к информационно-вычислительным ресурсам предприятия;

Role-Based Access Control (RBAC) - управления доступом к информации с целью эффективного разделения контрольных и исполнительских полномочий (separation of duty);

Business Activity Monitoring (BAM) - оперативный контроль функционирования предприятия;

Business Intelligence (BI) - анализ характеристик и тенденций работы предприятия;

Service-Oriented Architecture (SOA) - архитектурный стиль для построения сложных программных систем в виде набора универсально доступных и взаимозависимых служб, который используется для реализации, выполнения и управления службами;

Enterprise Service Bus (ESB) - среда коммуникаций между службами в рамках SOA.

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

BPM в архитектуре предприятия

Необходимость вовлечения практически всего корпоративного ПО в единую логику улучшения BPM-системы предприятия поднимает вопрос о роли и месте BPM в архитектуре предприятия (Enterprise Architecture, EA). EA является на сегодня устоявшейся практикой ИТ-департаментов по упорядочению информационно-вычислительной среды предприятия. В основе EA лежат следующие правила:

Текущая ситуация с информационно-вычислительной средой предприятия тщательно документируется как исходная точка as-is;

Желаемая ситуация документируется как конечная точка to-be;

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

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

Дисциплина BPM может решить основную проблему EA - дать объективную оценку производственно-хозяйственных возможностей (а не только информационно-вычислительных) того, что будет в точке to-be. Несмотря на то что EA описывает полную номенклатуру артефактов предприятия (его генотип), она не может достоверно сказать, какие изменения в этом генотипе влияют на конкретные производственно-хозяйственные характеристики предприятия, то есть на фенотип предприятия (cовокупность характеристик, присущих индивиду на определенной стадии развития).

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

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

В некотором смысле комбинация EA+BPM может стать своего рода навигатором, который обеспечивает руководство и практическую помощь в развитии бизнеса и ИТ при реализации генеральной линии предприятия.

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

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

Александр Самарин ([email protected]) - корпоративный архитектор ИТ-департамента правительства кантона Женева (Швейцария).

Process Frameworks для BPM

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

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

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

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

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

Process Framework, например, для бизнес-процесса обработки заказов, включает в себя базовую модель процесса со схемами действий для различных пользователей и ролей, избранные KPI из модели SCOR (The Supply-Chain Operations Reference-model) для процесса в целом и отдельных этапов, правила поддержки разных последовательностей обработки, например с учетом сегмента клиентов, целевые показатели для различных сегментов клиентов, типов продукции и регионов, а также панели индикации, помогающие контролировать особые ситуации.

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

Владимир Аленцев ([email protected]) - консультант по BPM и SOA , представительство Software AG в России и СНГ (Москва).

Архитектура эталонной модели искусственно включает два измерения:

измерение процесса , которое характеризует результаты процесса, являющиеся существенными измеримыми целями процесса;

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

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

Начальные процессы жизненного цикла состоят из категорий процессов поставщик - заказчик и инжиниринга.

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

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

Поддерживающие процессы жизненного цикла состоят из категории процесса поддержки.

Организационные процессы жизненного цикла состоят из категорий процессов управления и организации.

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

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

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

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

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

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

Есть шесть уровней возможности в эталонной модели.

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

Уровень 1 : Выполняемый. Цель процесса, в общем, достигнута. Достижение не может строго планироваться и отслеживаться. Персонал организации осознает, что процесс должен выполняться, и имеется общее согласие, что этот процесс выполняется, как требуется и когда требуется. Имеются определенные рабочие продукты процесса, и они свидетельствуют в пользу достижения цели.

Уровень 2 : Управляемый . Процесс вырабатывает рабочие продукты согласно определенным процедурам, планируется и отслеживается. Рабочие продукты соответствуют конкретным стандартам и требованиям. Основное различие от Выполняемого уровня в том, что при выполнении процесса теперь вырабатываются рабочие продукты, которые полностью требования к качеству в пределах определенного промежутка времени и выделенного ресурса.

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

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

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

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

Измерение процесса

В этом подразделе приводиться классификация процессов, принятых в организациях, занимающихся разработкой, эксплуатацией, приобретением, поставкой и поддержкой функционирования ПО. Классификация распознает пять категорий процессов, которые содержат все процессы. Категории и их процессы сопоставимы с теми процессами, которые определены в проекте стандарта ИСО/МЭК 12207, Информационная технология – Жизненный цикл процесса ПО, рассмотренного нами в разделе 2.

Как было отмечено выше, в эталонной модели процессы объединяются в три группы и пять категорий процессов:

начальные процессы жизненного цикла включают категории процесса инжиниринга и поставщик - заказчик;

поддерживающие процессы жизненного цикла включают категории процесса поддержки;

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

Индивидуальные процессы описаны в терминах шести компонентов.

Идентификатор процесса. Идентифицирует категорию и последовательный номер внутри этой категории. Схема нумерации различается между процессами верхнего уровня и процессами второго уровня. Идентификатор состоит из двух частей: сокращения категории (например, ENG для категории процесса инжиниринга) и номер (например, CUS. 1 обозначает Процесс Приобретения и CUS. 1.2 обозначает процесс второго уровня, Процесс Выбора Поставщика, который является составляющим (компонентным) процессом Процесса Приобретения).

Имя процесса. Описательная фраза, которая выделяет принципиальное свойство процесса (например, Выбор Поставщика).

Тип процесса. Имеется 3 типа процессов верхнего уровня (базисный, расширенный, новый) и 2 процесса второго уровня (компонентный, расширенный), которые имеют следующее отношение к процессам ИСО/МЭК 12207. Новые процессы дополнительны к тем, что определены в ИСО/МЭК 12207. Базисные процессы идентичны в предназначении процессам ИСО/МЭК 12207. Расширенные процессы дополняются на существующем процессе ИСО/МЭК 12207. Компонентные процессы группирует одно или большее количество действий ИСО/МЭК 12207 из того же самого процесса. Расширенные компонентные процессы группируют одно или большее количество действий ИСО/МЭК 12207 из того же самого процесса и включают дополнительный материал.

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

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

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

Для примера, приведем несколько процессов из каждой категории процесса.

CUS.1 Процесс Приобретения

Базисный процесс

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

Будет разработан контракт, который ясно выражает ожидания, обязанности и обязательства, как заказчика, так и поставщика;

Будет произведен продукт и/или услуга, что удовлетворит установленную потребность заказчика;

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

CUS.1.1 Процесс Подготовки Приобретения

Компонентный процесс CUS.1 – Процесса Приобретения

Цель Процесса Подготовки Приобретения состоит в том, чтобы установить потребности и цели приобретения. В результате успешной реализации процесса:

Будет установлена потребность в приобретении, разработке или расширении системы, программного продукта или процесса разработки ПО;

Будут сформулированы системные требования;

Будет разработана стратегия приобретения;

Будут определены приемочные критерии.

ENG.1 Процесс Разработки

Базисный процесс

Цель процесса Разработки состоит в том, чтобы трансформировать согласованный набор требований в функциональный программный продукт или программную систему, которые удовлетворяют установленным потребностям заказчика. В результате успешной реализации процесса:

Будет разработан программный продукт или программная система;

Будут разработаны промежуточные рабочие продукты, что показывает, что конечное изделие основывается на согласованных требованиях;

Будет установлена непротиворечивость между требованиями программного обеспечения и проектами программного обеспечения;

Данные тестирования будут показывать, что конечный продукт встречает согласованные требования;

Конечный продукт будет установлен в целевую среду и принят заказчиками.

ПРИМЕЧАНИЕ: Согласованные требования можно обеспечивать операцией процесса Приобретения (CUS. 1) или Процесса Установления Требований (CUS. 3).

ENG.1.1 Процесс Разработки и Анализа Системных Требований

Компонентный процесс ENG.1 – Процесса Разработки

Цель Процесса Разработки и Анализа Системных Требований состоит в том, чтобы установить системные требования (функциональные и нефункциональные) и архитектуру, идентифицируя, какие системные требования должны быть распределены к каким элементам системы и в какой версии. В результате успешной реализации процесса:

Будут разработаны системные требования, что соответствует установленным потребностям заказчика;

Будет предложено решение, идентифицирующее основные элементы системы;

Согласованные требования будут распределены каждому из основных элементов системы;

Будет разработана стратегия версии, определяющая приоритет для выполнения системных требований;

Системные требования будут одобрены и модифицированы, как и требуется;

Требования, предложенное решение и их связи будут сообщены всем заинтересованным сторонам.

SUP.1 Процесс Документирования

Расширенный Процесс

Цель Процесса Разработки Документации состоит в том, чтобы разработать и поддержать документы, которые записывают информацию, произведенную процессом или действием. В результате успешной реализации процесса:

Будет разработана стратегия, идентифицирующая документы, которые будут произведены в течение жизненного цикла программного продукта;

Будут определены стандарты, к которые должны обращаться за разработка документов;

Все документы, которые будут произведены процессом или проектом будут идентифицированы;

Все документы будут разрабатываться и издаваться в соответствии с определенными стандартами;

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

ПРИМЕЧАНИЕ - процесс поддерживает исполнение атрибута процесса 2.2 в тех примерах, где он введен.

MAN.1.1 Процесс Управления Проектом

Компонентный процесс MAN.1 – процесса Управления

Цель Процесса Управления Проектом состоит в том, чтобы идентифицировать, устанавливать, координировать и контролировать действия, задачи и ресурсы, необходимые для проекта создания продукта и/или встречи услуги согласованным требованиям. В результате успешной реализации процесса:

Будет определена область работ проекта;

Будет оценена выполнимость достижения целей проекта с доступными ресурсами и ограничениями;

Будут измерены и оценены задачи и ресурсы, необходимые для завершения работы;

Будут идентифицированы и проверяться интерфейсы между элементами проекта и другими проектами и организационными модулями,;

Будут разработаны и выполняться планы выполнения проекта;

Будет проверен и сообщаться прогресс проекта;

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

ПРИМЕЧАНИЕ - Этот процесс поддерживает исполнение атрибута процесса 2.1 в тех примерах, где он введен.

ORG.2 Процесс Усовершенствования

Базисный Процесс

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

Набор организационных активов процесса будет разработан и сделан доступным;

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

Измерение возможности

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

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

Для примера, приведем один из атрибутов третьего уровня возможности.

AП 3.1 Атрибут определение и преобразование процесса

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

Документация процесса, вместе с соответствующим руководством на подгонку стандартной документации процесса, будет определена, что способно обеспечить нормальную область выполнения процесса и функциональные и нефункциональные требования к рабочему продукту;

Выполнение процесса будет проводиться в соответствии с выбранной и/или приспособленной стандартной документацией процесса;

Исторические данные выполнения процесса будут собраны, во-первых, чтобы устанавливать и совершенствовать понимание поведения процесса, во-вторых, чтобы оценить потребности ресурса выполнения процесса;

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

Таблица 4.1.

Номер	Название
Уровень 1	Выполняемый процесс
АП 1.1	Атрибут выполнения процесса
Уровень 2	Управляемый процесс
AП 2.1	Атрибут управления выполнением
AП 2.2	Атрибут управления рабочим продуктом
Уровень 3	Установленный процесс
АП 3.1	Атрибут определения и преобразования процесса
АП 3.2	Атрибут ресурса процесса
Уровень 4	Предсказуемый процесс
AП 4.1	Атрибут измерения процесса
AП 4.2	Атрибут контроля процесса
Уровень 5	Оптимизирующий процесс
AП 5.1	Атрибут изменения (верификации) процесса
AП 5.2	Атрибут возможности дальнейшего улучшения

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

N Не достигнутый:

0 % - 15 % - есть маленькое или нет вообще подтверждения достижения определенного атрибута.

P Частично достигнутый:

16 % - 50 % - есть подтверждение надежного систематического метода к достижению определенного атрибута. Некоторые аспекты достижения могут быть непредсказуемы.

L В значительной степени достигнутый:

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

F Полностью достигнутый:

86 % - 100 % - есть подтверждение полного и систематического метода к полному достижению определенного атрибута. Никаких значительных недостатков не существуют в пределах определенной части организации.

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

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

Уровень возможности, достигнутый процессом, должен быть получен из рейтинга атрибута для этого процесса, согласно модели уровня возможности процесса, определенной в таблице 4.2. Цель этого требования состоит в том, чтобы гарантировать единообразие значений, когда уровень возможности процесса ссылается для процесса.

Ниже приведены таблицы, содержащие итоговые списки процессов, которые включены в эталонная модель (таблица 4.3) и соответствие процессов эталонной модели и процессов, определенные в проекте стандарта ИСО/МЭК 12207 (таблица 4.4).

Таблица 4.2

Шкала	Атрибуты процесса	Оценка
Уровень 1	Выполнение процесса	В основном или полностью
Уровень 2	Выполнение процесса Управление выполнением Управление рабочим продуктом	Полностью В основном или полностью В основном или полностью
Уровень 3	Выполнение процесса Управление выполнением Управление рабочим продуктом Ресурс процесса	Полностью Полностью Полностью В основном или полностью В основном или полностью
Уровень 4	Выполнение процесса Управление выполнением Управление рабочим продуктом Определение и преобразование процесса Ресурс процесса Измерение процесса Контроль процесса	Полностью Полностью Полностью Полностью Полностью В основном или полностью В основном или полностью
Уровень 5	Выполнение процесса Управление выполнением Управление рабочим продуктом Определение и преобразование процесса Ресурс процесса Измерение процесса Контроль процесса Изменение процесса Возможность дальнейшего улучшения	Полностью Полностью Полностью Полностью Полностью Полностью Полностью В основном или полностью В основном или полностью

Таблица 4.3.

			Процесс
Номер	Название	Номер			Название


				Приобретение (базисный)
				Подготовка приобретения (компонентный)
				Выбор поставщика (компонентный)
				Проверка поставщика (компонентный)
				Одобрение заказчика (компонентный)
				Поддержка (базисный)
				Установление требований (новый)
				Функционирование (расширенный)
				Функциональное использование (расширенный компонентный)
				Поддержка пользователя (расширенный компонентный)

				Разработка (базисный)
				Анализ и разработка системный требований (компонентный)
				Анализ требований ПО (компонентный)
				Разработка ПО (компонентный)
				Конструкция ПО (компонентный)
				Интеграция ПО (компонентный)
				Тестирование ПО (компонентный)
				Тестирование и интеграция системы (компонентный)
				Эксплуатация системы и ПО (базисный)
Поддерживающие процессы жизненного цикла

				Документирование (расширенный)
				Управление конфигурацией (базисный)
				Гарантия качества (базисный)
				Верификация (базисный)
				Проверка правильности (базисный)
				Совместный обзор (базисный)
				Проверка (базисный)
				Решение проблем (базисный)
				Измерение (новый)
				Повторного использования (новый)


				Управление (базисный)
				Управление проектом (компонентный)
				Управление качеством (новый)
				Управление риском (новый)

				Организационное выравнивание (новый)
				Процесс усовершенствования (базисный)
				Создание процесса (компонентный)
				Оценка процесса (компонентный)
				Усовершенствование процесса (компонентный)
				Управление человеческими ресурсами (расширенный)
				Инфраструктура (базисный)

Таблица 4.4.

Действия и процессы 12207

Процессы 15504

Начальные процессы жизненного цикла

Процесс приобретение

Процесс приобретения

базисный

Инициализация

Процесс подготовки приобретения

Компонента

Подготовка Заявки-для-Предложения [-заявка на подряд]

Процесс выбора поставщика

Компонента

Подготовка контракта и корректировка

Процесс выбора поставщика

Компонента

Проверка поставщика

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

компонента

Принятие и завершение

Процесс одобрения заказчика

компонента

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

базисный

Инициализация

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

базисный

Подготовка ответа

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

базисный

Контракт

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

базисный

Планирование

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

базисный

Выполнение и управление

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

базисный

Обзор и оценка

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

базисный

Поставка и завершение

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

базисный

Процесс установления требований

Процесс разработки

базисный

Реализация процесса

Процесс разработки

базисный

Анализ системных требований

компонента

Разработка архитектуры системы

Процесс разработки и анализа системных требований

компонента

Анализ требований ПО

Процесс анализа программных требований

компонента

Разработка архитектуры ПО

Процесс разработки ПО

компонента

Рабочий проект ПО

Процесс разработки ПО

компонента

Кодирование и тестирование ПО

Процесс конструкции ПО

компонента

Интеграция ПО

Процесс интеграции ПО

компонента

Тестирование квалификации ПО

Процесс тестирования ПО

компонента

Интеграция системы

компонента

Тестирование квалификации системы

Процесс тестирования и интеграции системы

компонента

Инсталляция ПО

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

базисный

Поддержка программ

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

базисный

Процесс функционирования

базисный

Реализация процесса

Процесс функционального использования

расширенная компонента

Функциональное тестирование

Процесс функционального использования

расширенная компонента

Функционирование системы

Процесс функционального использования

расширенная компонента

Поддержка пользователя

Процесс поддержки пользователя

расширенная компонента

Процесс эксплуатации

базисный

Реализация процесса

Процесс эксплуатации ПО и системы

базисный

Анализ проблем и модификаций

Процесс эксплуатации ПО и системы

базисный

Реализация модификации

Процесс эксплуатации ПО и системы

базисный

Принятие в эксплуатацию

Процесс эксплуатации ПО и системы

базисный

Миграция

Процесс эксплуатации ПО и системы

базисный

Утилизация ПО

Процесс эксплуатации ПО и системы

базисный

Вспомогательные процессы жизненного цикла

Процесс документирования

расширенный

Реализация процесса

Процесс документирования

расширенный

Разработка и развитие

Процесс документирования

расширенный

Продукция

Процесс документирования

расширенный

Эксплуатация

Процесс документирования

расширенный