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

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

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

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

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

Эффективное управление процессами требует наличия четырех ключевых ролей:

• организатор процесса
• владелец процесса
• руководитель процесса
• участник процесс

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

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

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

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

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

• Название
• Назначение
• Границы
• Входы
• Выходы
• Контроль
• Ресурсы

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

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

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

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

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

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

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

Классификация процессов

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

Типовая классификация процессов была разработана американским центром производительности и качества (APQC) Международной бенчмаркиноговой информационной службы, с помощью ряда международных организаций и в тесном сотрудничестве с Arthur Andersen & Co . Целью ее создания является помощь организациям в определении своих процессов и обеспечении общей структуры для улучшения понимания между компаниями, достижения выхода за рамки функциональных и отраслевых границ для общения и обмена информацией.

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

Управление и поддержка процессов

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

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

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

• выбор
• понимание
• эффективность
• анализ
• изменение
• внедрение изменений

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

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

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

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

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

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

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

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

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

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

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

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

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

Процесс трансформации и перестройки бизнеса

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

Определения этого понятия включают в себя:

"Фундаментальное переосмысление и радикальное изменение конструкции бизнес-процессов для достижения кардинальных улучшений в критических, актуальных показателях эффективности, таких, как стоимость, качество, сервис и скорость."
Hammer и Чемпи, 1993

"Пересмотр, перестройка и оптимизация бизнес-структур, процессов, методов работы, систем управления и внешних связей, через которые мы создаем и поставляем стоимость."
Talwar, 1993

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

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

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

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

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

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

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

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

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

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

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

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

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

BPR работает на нескольких уровнях, как операционном, так и управленческом.

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

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

см. также:

• 5 основных препятствий на пути непрерывного совершенствования
• Десять ключевых мероприятий для успешного осуществления проектов по улучшению процесса

© Статья подготовлена Андреем Гариным
по материалам зарубежных изданий
http://www.сайт/

размещено в разделе: Процессы

найти еще статьи

(The Software Engineering Institute’s Capability Maturity Model, SEI СММ) - широко.

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

Ключевые моменты.

А Модель технологической зрелости (Capability Maturity Model, СММ) является отличной точкой зрения для оценки схемы процесса, представленного в данной книге. Надлежащим образом реализованный и используемый по убеждению, этот процесс может достигать 3 или 4 уровня зрелости.

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

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

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

Е.1 ОБЩИЙ ОБЗОР СММ.

В СММ определены пять уровней зрелости процесса создания ПО, основанных на том, какие конкретные «ключевые» области процесса (Key Process Area, КРА) поддерживаются организацией. Уровень 1 (самый низший) соответствует организации с незрелым или неописанным.

процессом. Уровень 2 (воспроизводимый), уровень 3 (определенный), уровень 4 (управляемый) и уровень 5 (оптимизированный) описывают организации с более высокими уровнями зрелости процесса создания ПО. КРА, соответствующую каждому из этих уровней, можно охарактеризовать следующим образом:.

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

■ КРА уровня 3: большое внимание процессу организации, определение процесса организации, программа обучения, интегрированное управление созданием ПО, разработка программных продуктов, координация между группами, визуальные проверки.

ш КРА уровня 4: измерение и анализ параметров процесса, управление качеством, предотвращение появления дефектов.

■ КРА уровня 5: нововведения в технологию, управление изменением процесса.

Целью большинства организаций является достижение процесса уровня 3. Для определения зрелости организации используется оценка возможностей ПО (Software Capability Evaluation, SCE). SCE позволяет выяснить, действительно ли организация «говорит то, что она делает, и делает то, что говорит», посредством оценки процесса создания ПО, используемого в данной организации (обычно в виде отдельных положений, определяющих политику), и практики выполнения проектов. Политика организации - «говорит, что она делает» - и реализация проектов - «делает то, что говорит» - оцениваются по соответствующей КРА-схеме. Процесс оценки не является совершенным, однако он может служить хорошим относительным показателем зрелости процесса создания ПО.

Для типичной SCE в качестве одной из частей тщательной проверки применяется SEI Maturity Questionnaire («Вопросник для определения зрелости») . Это определение зрелости включает в себя подробный анализ, интервью и другие формы оценки. Данный вопросник, вообще говоря, используется в качестве отправной точки для создания контекста, в котором будет производиться оценка.

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

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

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

Таблица Е.1.

Распределение по уровням зрелости в индустрии ПО

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

■ Уровень 1 соответствует случайному (непредсказуемому) выполнению.

■ Уровень 2 позволяет достигать воспроизводимого выполнения от проекта к проекту.

■ Уровень 3 демонстрирует улучшение выполнения следующих друг за другом проектов в терминах затрат, сроков или качества.

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

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

На рис. Е.1 показано ожидаемое выполнение следующих один за другим проектов в организациях с различным уровнем зрелости.

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

Рис. Е.1. Ожидаемое выполнение проектов для различных уровней зрелости СММ.

■ Объективное понимание текущей зрелости.

■ Объективное понимание выполнения проекта в терминах затрат и сроков, поддающихся количественному выражению.

■ Реальное улучшение выполнения проекта.

■ Минимальное время, необходимое для подготовки к проведению оценки.

Зрелая организация и зрелые проекты понимают процесс и следуют ему. Им не приходится тратить время на подготовку к проверке. Если вы думаете, что ваша организация соответствует уровню 3, то ответьте на такой вопрос: сможет ли она выдержать внезапную проверку?.

Е.2 ПРАКТИЧЕСКОЕ УЛУЧШЕНИЕ ПРОЦЕССА.

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

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

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

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

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

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

Е.З ВОПРОСНИК ДЛЯ ОПРЕДЕЛЕНИЯ ЗРЕЛОСТИ.

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

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

Управление требованиями, уровень 2.

Используются ли ваши системные требования, относящиеся к ПО, в качестве базы для разработки и управления проектом?.

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

Вносятся ли необходимые уточнения в планы, рабочие материалы и виды деятельности по мере изменения требований, относящихся к ПО?.

▲ При итерационной разработке каждая новая итерация сопровождается новыми спецификациями версии и соответствующим обновлением технических рабочих продуктов. Назначением запросов на внесение изменений в ПО (SCO) типа 3 и является обращение к необходимым изменениям, вызванным изменением требований.

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

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

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

Используются ли измерения, проводимые для onpedejieuua состояния, работ, при управлении требованиями (например, общее число изменений требований, которые предложены, открыты, приняты и внесены в базовую версию)?.

A SCO типа 3 должны отслеживаться и учитываться при периодических оценках состояния.

Подвергается ли деятельность по управлению требованиями проверкам на подтверждение качества ПО (Software Quality Assurance, SQA)?.

А Контроль качества является обязанностью всех команд. Независимая организация, которая выполняет тестирование и на которую возлагается основная ответственность за обеспечение качества, просто не рассматривает вопросы управления требованиями; она активно участвует в создании спецификаций версии и в обеспечении ее соответствия набору требований. Совет по контролю за конфигурацией (Configuration Control Board, ССВ) также рассматривает изменения требований, содержащиеся в SCO. Кроме того, комплект рабочих продуктов требований применяется при осуществлении разработки, связанной с усовершенствованием моделей вариантов использования, комплекта рабочих продуктов проектирования, комплекта рабочих продуктов реализации и при демонстрациях комплекта рабочих продуктов внедрения.

Планирование проекта по созданию ПО, уровень 2.

1. Документируются ли оценки (размера, стоимости и сроков) для использования при планировании и для контроля за ходом выполнения проекта?.

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

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

Согласны ли все группы и лица, к которым это имеет отношение, со своими задачами, касающимися проекта по созданию ПО?.

А Декомпозиция работ (WBS) предоставляет механизм для проведения переговоров о поручениях между менеджером проекта и подчиненными ему менеджерами. SCO и ССВ обеспечивают механизм для ведения переговоров о поручениях более низкого уровня.

Следует ли проект политике организации при планировании работ по созданию ПО?.

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

Обеспечено ли планирование проекта по созданию ПО адекватными ресурсами (т.е. финансированием и опытным персоналом)?.

а Менеджер проекта по созданию ПО, ответственный за план, создает его и отвечает за его успех. Этот бизнес-план содержит ожидания и поручения, необходимые организации для определения отдачи от инвестиций по каждому виду работ. Адекватность ресурсов для планирования не определяется политикой. Хорошей отправной точкой может служить цифра 10% - приблизительно такая часть ресурсов проекта должна быть направлена на планирование и работы по управлению. Определение адекватных ресурсов специфично для каждого проекта. Эти оценки должны стать предметом тщательного изучения PRA и должны пересматриваться по достижении всех основных контрольных точек.

Используются ли измерения для определения состояния работ по планированию проекта по созданию ПО (т.е. завершенности этапов работ по планированию) ?.

А Метрики прогресса специально разработаны для того, чтобы обеспечить понимание критичных аспектов плана по сравнению с реальностью (прогресс разработки, прогресс тестирования, критерии оценки, соответствие которым уже достигнуто, реализованные сценарии, разработанные SL0C, число открытых SCO по сравнению с числом закрытых и т.д.).

7. Проверяет ли менеджер проекта работы по планированию проекта по созданию ПО как на регулярной основе, так и при наступлении определенных событий?.

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

Отслеживание и контроль за выполнением проекта по созданию ПО, уровень 2.

Сравнимы ли реальные показатели выполнения проекта (сроки, размеры и затраты) с оценками, содержащимися в планах по созданию ПО?.

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

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

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

Согласовываются ли изменения в распределении обязанностей со всеми заинтересованными группами и лицами?.

А Изменения в распределении обязанностей обсуждаются при изменении WBS, планов разработки ПО и оценок состояния. Поручения более низкого уровня также рассматриваются ССВ, отслеживаются по SCO и отражаются в описаниях версий.

Следует ли проект политике организации по отслеживанию и контролю за деятельностью по разработке ПО?.

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

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

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

Используются ли измерения для определения состояния работ по отслеживанию и контролю за ПО (например, суммарных трудозатрат на выполнение работ по отслеживанию и контролю)t.

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

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

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

Управление субподрядчиками по созданию ПО, уровень 2.

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

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

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

Вносятся ли изменения в контракты субподряда с обоюдного согласия основного подрядчика и субподрядчиков?.

А Здравый смысл подсказывает, что это всегда должно быть именно так.

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

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

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

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

Следует ли проект политике организации по работе с субподрядчиками?.

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

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

А Обучение зависит от конкретной организации.

Используются ли измерения состояния работ для управления субподрядом по созданию ПО (например, соответствие срокам с учетом дат планируемых поставок и трудозатрат, израсходованных на управление субподрядом)?.

А Субподрядчики должны управляться точно так же, как генеральный подрядчик.

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

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

Подтверждение качества ПО, уровень 2.

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

Планируются ли работы по SQA ?.

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

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

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

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

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

Рассматриваются ли случаи несоответствия стандартам, которые не региены в рамках проекта, вышестоящим руководством (например, отклонения от применяемых стандартов)?.

а Это является одной из прямых задач утверждения планов разработки и оценок состояния со стороны PRA (Project Review Authority). Регулярные PRA-рассмотрения касаются любых предполагаемых отклонений от политики организации по мере прогресса проекта.

Следует ли проект политике организации по реализации SQA ?.

А Политика организации и планы разработки ПО должны обеспечивать SQA-политикой организацию и проект соответственно.

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

А Адекватность ресурсов, выделяемых на SQA, не определяется политикой. Хорошей контрольной цифрой являются 25% от всех работ в рамках проекта, направляемых на работу команды по выполнению оценок (тестирование, оценка, метрики, ССВ). Несмотря на то, что адекватность ресурсов специфична для каждого конкретного проекта, эти оценки, очевидно, должны выполняться под тщательным контролем PRA.

Используются ли измерения для определения затрат и сроков по работам, связанным с SQA (например, объем завершенных работ, трудозатраты и финансовые затраты по сравнению с запланированными)?.

А Основа содержится в WBS, а периодические оценки Состояния позволяют отслеживать реальность по сравнению с планами для всех видов деятельности.

Рассматриваются ли работы по SQA совместно с вышестоящим руководством на регулярной основе?.

А Это одна из основных задач PRA-рассмотрений и PRA-утверждения плана разработки ПО.

Управление конфигурацией ПО, уровень 2.

Все виды деятельности и весь персонал вовлекаются в управление конфигурацией ПО (Software Configuration Management, SCM) точно так же, как в SQA. Независимая команда, выполняющая оценку, принимает на себя основную ответственность за деятельность по управлению конфигурацией, включая сопровождение базы данных SCO, администрирование ССВ и управление базовой версией. Эти виды работ должны выполняться параллельно (для экономии времени) и независимо (для разнообразия технических точек зрения). Вообще говоря, действия по SCM выполняются всеми разработчиками ПО и поддерживаются прежде всего средой разработки ПО. Для ответов на эти вопросы деятельность независимой команды по оценке максимально приближена к определению SCM, принятому в СММ.

Были ли запланированы работы по управлению конфигурацией в рамках проекта?.

А План разработки ПО автоматически должен содержать и поддерживать работы по SCM.

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

A SCO и все рабочие продукты находятся под управлением конфигурацией.

Следует ли проект зафиксированной процедуре контроля над изменениями, вносимыми в элементы/модули конфигурации?.

a SCO обеспечивают механизм контроля над изменениями в онлайновом режиме, как это записано в политике организации и в плане разработки ПО.

Распространяются ли среди заинтересованных групп и лиц стандартные отчеты по базовым версиям ПО (например, протоколы заседания ССВ, обзор запросов на внесение изменений, отчеты о состоянии)?.

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

Следует ли проект политике организации в области реализации работ по управлению конфигурацией ПО?.

А Это обеспечивается политикой организации и планами разработки ПО.

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

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

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

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

Производятся ли регулярные проверки на соответствие базовых версий ПО и их документации (например, SCM-группой)?.

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

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

1. Координируется ли в рамках организации деятельность по разработке и совершенствованию процесса создания ПО (например, специальной группой по разработке процесса создания ПО)?.

А Все планы по разработке и оценке состояния рассматриваются и утверждаются органом, ответственным за процесс разработки ПО (Software Engineering Process Authority, SEPA). Эти механизмы обеспечивают координацию и непротиворечивость в рамках организации.

Регулярно ли оценивается процесс создания ПО в вашей организации?.

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

Следует ли ваша организация документированному плану разработки и усовершенствования своего процесса создания ПО?.

A SEPA должен документировать этот план и приложить его к политике организации.

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

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

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

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

Применяются ли измерения для определения состояния деятельности по разработке и усовершенствованию процесса создания ПО, используемого в данной организации (например, объем трудозатрат на оценку и усовершенствование процесса создания ПО)?.

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

Регулярно ли деятельность по разработке и совершенствованию процесса создания ПО рассматривается вышестоящим руководством?.

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

Определение процесса, используемого организацией, уровень 3.

1. Разработан и поддерживается ли вашей организацией стандартный процесс создания ПО?.

А Политика организации определяет стандарт процесса создания ПО, который периодически обновляется.

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

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

Следует ли организация заданной политике в области разработки и поддержки своего стандартного процесса создания ПО?.

А Политика организации определяет стандарт процесса и его поддержку.

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

А Обучение зависит от конкретной организации.

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

А Информация о R0I от деятельности SEPA должна храниться в виде приложения к политике организации.

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

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

Программа обучения, уровень 3.

Планируется ли деятельность по обучению?.

А Обучение зависит от конкретной организации. .

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

А Обучение зависит от конкретной организации.

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

А Обучение зависит от конкретной организации.

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

А Обучение зависит от конкретной организации.

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

А Обучение зависит от конкретной организации.

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

А Обучение зависит от конкретной организации.

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

А Обучение зависит от конкретной организации.

Управление интегрированным ПО, уровень 3.

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

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

Осуществляется ли планирование и управление процессом в соответствии с описанным для проекта процессом создания ПО?.

А Менеджер проекта по созданию ПО составляет и утверждает план разработки ПО, он же является ответственным за план при периодических PRA-обзорах.

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

А Политика организации - это политика, зафиксированная в виде документов.

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

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

Используются ли измерения для определения эффективности деятельности по управлению интегрированным ПО (например, частота, причины и размеры затрат на изменение планов)?.

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

Подвергается ли деятельность по управлению проектом и промежуточные продукты, получаемые в результате ее осуществления, SQA-рассмотрению и проверкам?.

а План разработки ПО рассматривается как PRA, так и SEPA (который отвечает за SQA в данной организации).

Разработка программного продукта, уровень 3.

Создаются ли промежуточные программные продукты в соответствии с определенным для данного проекта процессом создания ПО?.

А Менеджер проекта по созданию ПО ответственен за выполнение плана разработки ПО. Любые отклонения от плана или от стандартов (или от того и другого одновременно) периодически рассматриваются при оценке состояния, после чего вносятся соответствующие изменения в последующие итерации или базовые версии продуктов.

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

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

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

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

Обеспечивается ли выполнение заданий по разработке ПО адекватными ресурсами (например, финансированием, обученным персоналом и необходимым инструментарием)?.

А Адекватность ресурсов, выделяемых на разработку ПО, не определяется политикой. Хорошей контрольной отметкой может служить цифра 50% - именно такую часть всех трудозатрат следует направлять на выполнение задач по разработке ПО: 10% - на описание требований, 15% - на проектирование и 25% - на реализацию компонентов. Определение адекватности ресурсов и персонала специфично для каждого конкретного проекта и должно тщательно изучаться PRA.

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

а Основная цель вычисления метрик и их рассмотрения при выполнении оценок состояния заключается в определении прогресса и качества.

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

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

Координация между группами, уровень 3.

1. Сотрудничают ли группа по разработке ПО и другие группы разработчиков в процессе выполнения проекта с заказчиком для определения системных требований?.

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

Согласны ли группы разработчиков с возложенными на них обязанностями, которые зафиксированы в общем плане проекта?.

А Планы и поручения содержатся в планах разработки ПО, спецификациях версий и WBS.

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

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

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

А ССВ, PRA и команды по проведению демонстраций как раз и являются междисциплинарными командами.

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

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

Используются ли измерения для определения состояния деятельности по координации между группами (например, трудозатрат на поддержку одной группой разработчиков ПО других групп)?.

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

7. Рассматривается ли деятельность по координации между группами менеджером проекта на регулярной основе и при наступлении определенных событий?.

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

Экспертные оценки, уровень 3.

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

Запланированы ли экспертные оценки?.

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

Отслеживается ли деятельность по устранению дефектов, обнаруженных при экспертных оценках, до тех пор, пока они не будут исправлены?.

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

Следует ли проект политике организации в области выполнения экспертных оценок?.

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

Проходят ли участники экспертных оценок необходимое обучение для выполнения своих обязанностей?.

А Обучение зависит от конкретной организации.

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

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

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

А Менеджеры проектов по созданию ПО, ССВ и PRA постоянно следят, чтобы эти виды деятельности доводились до конца.

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

Следует ли проект документированному плану управления количественными показателями процесса?.

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

Контролируется ли ход описанного процесса по созданию ПО в рамках данного проекта количественно (например, посредством использования количественных методов анализа)?.

А Все данные собираются и передаются SEPA в процессе выполнения оценок состояния. Эти метрики служат для установления обратной связи при планировании каждой последующей итерации.

Известны ли количественные характеристики возможностей стандартного процесса по созданию ПО в рамках данного проекта?.

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

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

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

Адекватны ли ресурсы, выделяемые на осуществление деятельности по управлению количественными показателями процесса (например, финансирование, вспомогательные программные инструменты и программа выполнения измерений для данной организации)?.

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

Используются ли измерения для определения состояния деятельности по управлению количественными показателями процесса (например, затраты на управление количественными показателями процесса и на достижение контрольных точек при управлении количественными показателями процесса)?.

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

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

Управление качеством ПО, уровень 4.

Запланирована ли в рамках проекта деятельность по управлению качеством ПО?.

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

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

А Для этого существуют спецификации версий и соответствующие им демонстрации, описания версий и метрики.

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

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

Следует ли проект политике организации в области управления качеством ПО?.

А Политика организации действительно определяет механизмы управления качеством ПО (спецификации версий, описания версий, параметры качества, PRA и CCB/SC0).

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

а Вопрос не рассматривается.

После выявления причин дефектов расставляются ли наиболее распространенные причины по значимости и производится ли их систематическое устранение?.

А Вопрос не рассматривается.

Следует ли проект политике организации в области деятельности по предотвращению дефектов?.

А Вопрос не рассматривается.

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

А Обучение зависит от конкретной организации.

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

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

Подвергаются ли деятельность по предотвращению дефектов и ее промежуточные продукты SQA-рассмотрениям и проверкам?.

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

Управление изменением технологии, уровень 5.

А На каждой новой итерации при осуществлении проекта имеется возможность внесения усовершенствований в план создания ПО. Политика организации также нуждается в периодической переоценке и усовершенствовании.

Следует ли организация принятой политике в области реализации усовершенствований процесса создания ПО?.

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

Требуется ли обучение усовершенствованиям процесса создания ПО для руководящего состава и для технических работников?.

А Обучение зависит от конкретной организации.

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

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

7. Рассматривается ли деятельность по совершенствованию процесса создания ПО вышестоящим руководством на регулярной основе?.

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

Е.4 ВОПРОСЫ, КОТОРЫЕ НЕ ВОШЛИ В «ВОПРОСНИК ДЛЯ ОПРЕДЕЛЕНИЯ ЗРЕЛОСТИ».

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

Отчетность персонала, уровень 2.

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

Автоматизирована ли «круговая» разработка?.

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

Адекватно ли автоматизировано регрессионное тестирование?.

Используются ли случайные сценарии и внеурочное тестирование для обеспечения статистического тестового покрытия?.

Интегрированы ли редакторы языков программирования, среда управления конфигурацией, компилятор и отладчик?.

Разработка архитектуры, уровень 3.

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

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

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

Джерри Фэй

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

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

Приведенное ниже объяснение 10-этапного плана усовершенствования процесса, используемого в компании "Raab Karcher Electronics Inc.", Сан-Диего, шт. Калифорния, демонстрирует его эффективность.

На стадии планирования

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

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

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

На стадии осуществления

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

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

План усовершенствования процесса и отчет о продвижении

Raab Karcher TQM Process Improvement Plan = План усовершенствования процесса компании "Raab Karcher" для полного управления качеством

Project Title = Наименование проекта

Manifest process improvement = Усовершенствование процесса составления грузовой декларации

Project No. OFC-1-96 = Проект № OFC-1-96

Goal/Objective = Цель/Задача

To reduce the number of wrong parts shipped to customers as measured by problems found after manifest = Уменьшить число неправильных частей, отгруженных заказчикам, которые выявлены в связи с проблемами, обнаруженными после составления грузовой декларации

Owner(s) = Владелец (владельцы) процесса

The manifest team = Группа по подготовке грузовой декларации

Customers = Заказчики

All external customers, sales, and marketing = Все внешние заказчики, торговые точки, рынок

Management Indicators = Индикаторы управления

Reduced errors from manifest area by 80% = Снижение ошибок в области грузовой декларации на 80%

Increased productivity (measured by completed shipments) = Повышенная производительность (измеренная по завершенным поставкам)

Current Process Flow = Текущая последовательность операций

Receive parts from picking = Получение частей из сортировки

Scan all parts in bin = Проверка всех частей в бункере

Print packing slip = Распечатка ошибок упаковки

Parts missing? = Части пропущены?

All parts are parts of order? = Все части являются заказанными частями?

Box and weigh parts = Упаковка частей в ящик и взвешивание

Ship to customer = Отгрузка заказчику

Recount order = Пересчет заказа

Too many parts? = Слишком много частей?

Return to stock = Возврат на склад

Improvement Areas = Участки усовершенствования

Bold Italics - Measurement Areas = Полужирный курсив - Участки измерения

October = Октябрь

Milestones = Основные этапы

Implement lockout feature = Реализация блокирующих свойств

Monitor progress = Контроль продвижения

TQM Progress Plan = План продвижения полного управления качеством

Project No OFC-1-96 = Проект № OFC-1-96

Initiative = Инициатива

Benefit = Польза

Estimated Completion Date = Расчетная дата выполнения

Comments = Комментарии

Add rover to the warehouse = Добавление на склад мобильного робота

Review bins prior to manifest = Просмотр бункера перед составлением грузовой декларации

Complete = Выполнено

Install lockout feature = Установка блокирующих свойств

Stop process at problem point = Остановка процесса в проблемной точке

Reestablish rotation = Переустановка последовательности операций

Reduce boredom = Уменьшение скуки

Change conbin selection = Изменение выбора соединенного бункера

Reduced mixed shipments = Уменьшение смешанных отгрузок

Add additional manifest station = Добавление дополнительной станции подготовки грузовых деклараций

Reduce stress during peak = Уменьшение напряжения во время максимумов нагрузки

Actionee: George Evans = Действующее лицо: Джордж Эванс

Training upgrade = Повышение квалификации посредством обучения

Ensure training is consistent = Обеспечиваемое обучение является последовательным

Program is complete = Программа завершена

Letter designated on last label = Буква, указываемая на последней фирменной табличке

Reminder to empty conbin = Напоминание о пустом соединенном бункере

На стадии проверки

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

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

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

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

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

Компания "Raab Karcher Electronics Inc." сохраняет планы усовершенствования процессов и планы продвижения полного управления качеством в корпоративной компьютерной сети так, что они могут быть просмотрены любым интересующимся продвижением данной группы. Шаблон для плана усовершенствования процесса сделан в Microsoft Power Point. Программа Visio для Windows использовалась для составления блок-схем. Для построения графиков с данными использовался Microsoft Project.

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

Успех плана усовершенствования процесса у первой группы компания "Raab Karcher Electronics Inc." стал большим стимулом для его использования. Эта группа сократила возвращаемые материальные ценности с 500 000 долларов США до менее, чем 1000 долларов США.

Когда эта статья было опубликована в октябре 1997 года, Джерри Фей был менеджером по обеспечению качества в компании "Raab Karcher Electronics Inc.", Сан-Диего, штат Калифорния. Он получил степень бакалавра в области администрации бизнеса в Редландском университете в Калифорнии. Фей был членом Американского общества качества и дипломированным аудитором по качеству.

Коллектив авторов Harvard Business School Press Глава из книги «Руководство по улучшению бизнес-процессов »
Издательство «Альпина Паблишер»

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

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

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

Формальные методики и стандарты

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

Таблица 1. Формальные методики и стандарты совершенствования бизнес-процессов

Название	Описание
Шесть сигм (Six Sigma)	Строгая, основанная на фактах методика, позволяющая выявлять и устранять недостатки в любых процессах. Направлена на всемерное повышение эффективности, надежности и потребительской ценности товаров и услуг. Методика «Шесть сигм» была разработана в 1980-е годы в компании Motorola, когда ее руководство осознало, что в ходе использования продукты с минимумом изначальных недочетов отказывают значительно реже. Греческая буква сигма обозначает отклонение от стандарта.
Всеобщее управление качеством (Total Quality Management, TQM)	Стратегия менеджмента, цель которой - внедрение заботы о качестве в каждый процесс, осуществляемый в организации, и всемерное поощрение действий сотрудников, направленных на повышение удовлетворенности клиентов и снижение издержек. Активно внедрялась в Японии после Второй мировой войны американским статистиком и преподавателем Эдвардом Демингом. Позднее Джозеф Джуран расширил концепцию управления качеством, отойдя от узкостатистического толкования и уделив максимум внимания человеческой составляющей.
ISO 9000	Серия стандартов систем управления качеством (ISO). Эти стандарты не гарантируют качество конечного товара или услуги - скорее они удостоверяют тот факт, что компания использует сертифицированные бизнес-процессы. Стандарты ISO 9000 находятся в ведении структур, отвечающих за аккредитацию и сертификацию.
Реинжиниринг бизнес-процессов (BPR)	Методика менеджмента, обеспечивающая радикальное совершенствование рабочих процессов как внутри отдельной организации, так и между организациями с целью значительного повышения эффективности деятельности. Стремительный взлет этой методики относится к началу 1990-х годов, когда Майкл Хаммер и Джеймс Чампи опубликовали свой революционный бестселлер «Реинжиниринг корпорации».

С чего начинается улучшение бизнес-процессов

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

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

Что бы вы сделали?

Pedal Power: неутешительные итоги

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

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

Вот что предложил бы ему наш эксперт.

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

Чем выгоден менеджмент бизнес-процессов

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

Шесть этапов совершенствования бизнес-процессов

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

1. Планирование. Выберите бизнес-процесс, который собираетесь усовершенствовать, определитесь с задачами и масштабами изменений, соберите команду.
2. Анализ. Тщательно изучите бизнес-процесс, который собираетесь усовершенствовать.
3. Редизайн. Определитесь с тем, какие именно изменения вы собираетесь внести в избранный процесс.
4. Привлечение ресурсов. Обеспечьте наличие персонала, оборудования и других ресурсов, необходимых для осуществления намеченных изменений.
5. Внедрение. Внесите необходимые изменения.
6. Непрерывное совершенствование. Регулярно оценивайте эффективность выбранного процесса и при необходимости вносите дополнительные изменения.

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

Планирование улучшения бизнес-процессов

Чтобы составить план изменения бизнес-процессов, вам необходимо будет предпринять следующие шаги:

• Выявить признаки проблемы
• Выбрать процесс, который необходимо улучшить
• Определить масштабы, цели и график изменений
• Собрать команду, которая будет заниматься совершенствованием бизнес-процессов
• Грамотно поставить задачу команде

Выявляем признаки проблемы

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

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

Выбираем процесс, который необходимо улучшить

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

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

Таблица 2. Матрица выбора процессов Джо

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

Более подробную информацию см. в разделе «Расставляем приоритеты при совершенствовании бизнес-процессов: полезные советы».

Расставляем приоритеты при совершенствовании бизнес-процессов: полезные советы

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

Определяем масштабы, цели и график изменений

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

Соберите команду, которая будет заниматься совершенствованием бизнес-процесса

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

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

Ставим задачу команде

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

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

Усовершенствование процесса получения крекинг-газа пиролизом нафты

Корчагина Татьяна Константиновна,

кандидат химических наук, доцент,

Оноприенко Дарья Андреевна,

студент-магистрант 6-го курса.

Волгоградский государственный технический университет.

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

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

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

Производство крекинг-газа на ОАО «КАУСТИК» введено в эксплуатацию в 1972 году. Процесс осуществляется непрерывным методом высокотемпературного пиролиза углеводородного сырья .

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

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

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

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

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

Литература

1. Лебедев Н.Н. Химия и технология основного органического синтеза. – М: КолосС, 2013 г.

2. Литвинцев И.Ю. Пиролиз – ключевой процесс нефтехимии / Соросовскийй образовательный журнал №12. – 1999 г.

3. Мухина Т.Н., Баранов Н.Л., Бабаш С.Е. и др. Пиролиз углеводородного сырья.1987 г.-240 стр.

4. Основной технологический регламент цеха № 102 ОАО «Каустик». Волгоград, 2008.

5. Паушкин Я.М. / Нефтехимический синтез в промышленности / / Я. М. Паушкин – М.: Наука, 1996г. – 536 с.

6. Патент № 2103318. Российская федерация / А. Д. Абдуллаев; С. В. Хлопов; В. Ю. Колотов; А. Ф. Бабиков; Н. А. Корчевин; заявитель и патентообладатель Акционерное общество открытого типа «Ангарская нефтехимическая компания». Дата публикации 27.01.1998.