Как оценить усовершенствование рабочих процессов. План улучшения бизнес-процессов Управление и поддержка процессов

Один из способов применения концепции решения проблем (kaizen) в корпорации "Фиделити" (Fidelity) - использование программы оценки и усовершенствования про­цесса. Используя эту программу, многие службы сервиса для клиентов корпорации "Фиделити" (Fidelity) разработали контрольные списки критериев оценки для каждого отдельного бизнес процесса.

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

Определил свои рабочие процессы

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

Обучил весь персонал выполнять работу согласно образцам

Сделал так, чтобы персонал, выбранный наугад, ежедневно брал и оценивал образцы работы, и каждую неделю заносил результаты в таблицы по контролю процес­сов своего отдела

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

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

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

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

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

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

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

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

Цели усовершенствования не диктуются из главного офиса корпорации. Каж­дая группа должна сама: (1) Установить свои собственные цели для усовершенствова­ния; (2) использовать данные, чтобы определить наиболее проблемные места; (3) изме­нить процесс работы так, чтобы решить обнаруженные проблемы.

Например, контрольный список программы оценки и усовершенствования про­цесса для оценки корреспонденции с клиентом состоит из следующих пунктов:

1. Было ли во время проштамповано письмо?

2. Поступило ли подтверждение в "Фиделити " (Fidelity) о том, что письмо было проштамповано, в тот же день, когда это было сделано?

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

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

5. Придерживались ли мы инструкций?

6. Сообщили ли мы во время первого общения с клиентом свое имя, номер теле­фона и ожидаемые временные рамки?

7. Если мы в первый раз не оправдали надежд и ожиданий клиента, перезвонили ли мы ему и попытались восстановить его надежды?

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

9. Длился ли основной процесс пять дней или меньше?

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

11. Были ли все наши действия документированы?

12. Были ли нами определены, затронуты и даны ответы на вопросы внутри кор­порации, которые возникли в результате решения проблем клиента?

13. Были ли решены/затронуты все проблемы или даны ответы на вопросы клиен­та?

14. Были ли верно внесены все корректировки в счет клиента?

15. Соблюдались ли все инструкции представителем?

16. Воспользовались ли мы всеми возможностями, чтобы поразить клиента?

17. Были ли правильно расставлены коды на всей документации?

1

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

система менеджмента качества

процесс постоянного улучшения

четыре стадии осуществления

методология решения проблем

внедрение улучшенного процесса

1. ГОСТ Р ИСО 9001-2008 Системы менеджмента качества. Требования. – М. : Стандартинформ, 2009. – 30 с.

2. Пономарев С.В. Управление качеством продукции. Инструменты и методы менеджмента качества: учеб. пособ. / С.В. Пономарев [и др.] – М. : РИА «Стандарты и качество», 2005. – 248 c.

3. Мищенко С.В. Использование методологии решения проблем, инструментов и методов менеджмента качества при выполнении научных исследований / С.В. Мищенко, С.С.С. Аль-Бусаиди, Г.А. Соседов и др. // Вестник ТГТУ. – 2012. – № 1. – С. 6-19.

4. Rampersad H.K. Total Quality Management: An Executive Guide to Continuous Improvement. – Berlin-Heidelberg: Springer – Verlag, 2001. – 190 p.

Процесс «8.5.1 Постоянное улучшение» по требованиям ГОСТ Р ИСО 9001-2008 следует рассматривать как основу систематической упорядоченной работы (в составе команды), направленной на непрерывное улучшение качества всех процессов и видов деятельности организации, внедрившей систему менеджмента качества (СМК). Для претворения в жизнь процесса постоянного улучшения каждый сотрудник организации должен рассматривать непрерывное совершенствование как нечто обычное .

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

Рассмотрим подробнее содержание работ, выполняемых на каждой стадии процесса постоянного улучшения:

I . Выбор процесса (-ов), требующего (-их) первоочередного улучшения.

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

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

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

1.1 Формирование команды экспертов из состава высшего руководства организации.

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

Рис. 1. Графическая модель осуществления процесса постоянного улучшения в СМК организации.

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

При определении списка таких процессов следует использовать:

• результаты внутренних и внешних аудитов (проверок) (п. 8.2.2 );
• результаты анализа данных (п. 8.4 ), предоставляющих информацию:

а) об удовлетворенности потребителей (п. 8.2.1 );

б) по определению требований к продукции (п. 7.2.1 );

в) по мониторингу и измерению процессов (п. 8.2.3 ) и продукции (п. 8.2.4 );

• результаты корректирующих (п. 8.5.2 ) и предупреждающих (п. 8.5.2 ) действий;
• результаты анализа со стороны руководства (п. 5.6 ), в том числе анализа политики (п. 5.3 ) и целей в области качества (п. 5.4.1 ).

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

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

Из принципа Парето исходит следующее . Если на предыдущем этапе (1.2) были отобраны N процессов, то до 70...80% суммарных убытков при выполнении рассматриваемых процессов создаются только 20...30% процентами этих процессов. Если N = 5, то только 1...2 процесса обуславливают до 70...80% экономических потерь.

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

1.4 Принятие решения о том, какой процесс будет подвергнут улучшению.

Если бы у первого лица (ректора, генерального директора) организации было бы неограниченное количество ресурсов для осуществления процесса постоянного улучшения, то он выделил бы необходимые ресурсы каждому владельцу процесса и сказал бы: «Улучшайте свой процесс!». На практике любой руководитель имеет очень серьезные ограничения в доступных ему ресурсах. Из-за этого для совершенствования каждого требующего первоочередного улучшения процесса во многих случаях приходится обращаться в банк для получения кредита.

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

II . Описание выбранного процесса.

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

2.1. Формирование команды специалистов для улучшения отобранного процесса.

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

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

2.2. Определение границ процесса и интерфейсов его взаимодействия с другими процессами.

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

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

2.3. Описание процесса в виде поточной диаграммы (блок-схемы), цепочки или сети подпроцессов (операций).

На этапе 2.3 второй стадии члены команды специалистов описывают рассматриваемый процесс с применением инструментов и методов менеджмента качества, например таких, как :

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

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

2.4. Определение контрольных точек и критических этапов (подпроцессов, операций) рассматриваемого процесса.

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

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

III . Улучшение процесса (первоначально в малом масштабе) на основе применения методологии решения проблем.

На этой третьей стадии осуществляют собственно само улучшение рассматриваемого процесса. При этом следует использовать методологию решения проблем , представляющую собой детализированный вариант цикла улучшения Деминга Plan-Do-Chek-Act(PDCA). В соответствии с рекомендациями методологии решения проблем (МРП) на третьей стадии каждой итерации процесса постоянного улучшения следует осуществить следующие этапы работы.

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

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

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

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

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

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

Правильно сформулированная постановка проблемы :

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

3.2. Сбор статистических данных и определение (на основе принципа Парето) наиболее дорого обходящихся главных несоответствий (дефектов).

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

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

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

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

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

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

3.3. Идентификация причин главного несоответствия (дефекта).

1. применение экспертного метода;
2. применение статистических данных о причинах несоответствий.

3.3.1. Использование экспертного метода.

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

1. manpower (персонал, его квалификация, стаж, пол и др.);
2. machine (машины, станки, оборудование, изготовители и т.п.);
3. material (материал, сырье, комплектующие, поставщики);
4. method (метод, технология, технологический режим, прием);
5. measurement (измерение, метод, тип прибора, класс точности и т.п.);
6. media (окружающая среда, температура, влажность воздуха, солнечное излучение, магнитные и электрические поля и т.п.).

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

Из принципа Парето понятно, что до 70...80% случаев проявления главного дефекта возникают из-за действия не более чем 20...30% причин. Для определения основных причин главного несоответствия в этом случае следует рекомендовать использование экспертных методов.

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

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

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

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

3.3.2. Использование статистических данных при определении основных причин главного несоответствия-дефекта.

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

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

3.4. Генерирование возможных путей устранения ранее выявленных причин.

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

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

3.5. Планирование действий, направленных на устранение основных причин главного несоответствия.

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

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

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

Рассмотренные выше пять этапов 3.1...3.5 методологии решения проблем представляют собой первую фазу (Plan) цикла улучшения Деминга PDCA.

3.6. Осуществление запланированных действий по улучшению (первоначально в малом масштабе).

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

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

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

1) построение математической модели улучшаемого процесса и аппаратов для его осуществления;

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

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

3) проектирование режимных параметров нового улучшенного процесса и разработка конструкций аппаратов для его улучшения;

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

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

6) обучение и тренинг на рабочих местах операторов и специалистов, вовлеченных в выполнение улучшенного процесса;

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

Этап 3.6 совпадает со второй фазой (Do) цикла улучшения PDCA Деминга.

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

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

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

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

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

• повторный сбор статистических данных (этап 3.2) для уточнения нового главного несоответствия (этап 3.3);
• повторная идентификация причин главного несоответствия (дефекта) и выбор новой основной причины (п. 3.4);
• внесение изменений и уточнение плана действий, направленных на устранение новой основной причины (п. 3.5);
• изменение конструкции аппаратуры и осуществление процесса при уточненных значениях режимных параметров процесса (п. 3.6).

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

Этап 3.7 эквивалентен третьей фазе (Check) цикла улучшения PDCA Деминга.

3.8. Разработка стандартизованной процедуры осуществления улучшения.

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

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

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

IV . Полномасштабное внедрение улучшенного процесса и выполнение стандартизованной процедуры.

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

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

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

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

4.2. Приобретение необходимых комплектующих узлов, деталей и их монтаж.

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

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

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

4.4. Полномасштабное внедрение стандартизованной процедуры во всех подразделениях.

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

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

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

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

1) после внедрения нового улучшенного процесса необходимо удостовериться в том, что

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

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

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

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

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

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

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

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

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

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

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

Рецензенты:

• Чуриков А.А., д.т.н., профессор кафедры «Управление качеством и сертификация», ФГБОУ ВПО «Тамбовский государственный технический университет», г. Тамбов.
• Герасимов Б.И., д.т.н., д.э.н., профессор кафедры «Экономический анализ и качество», ФГБОУ ВПО «Тамбовский государственный технический университет», г. Тамбов.

Библиографическая ссылка

Мищенко С.В., Соседов Г.А., Савин К.Н., Аль-Бусаиди С.С.С., Пономарев С.В. РЕКОМЕНДАЦИИ ПО ВЫПОЛНЕНИЮ ПРОЦЕССА ПОСТОЯННОГО УЛУЧШЕНИЯ В СИСТЕМЕ МЕНЕДЖМЕНТА КАЧЕСТВА ОРГАНИЗАЦИИ // Современные проблемы науки и образования. – 2012. – № 2.;
URL: http://science-education.ru/ru/article/view?id=5666 (дата обращения: 01.02.2020). Предлагаем вашему вниманию журналы, издающиеся в издательстве «Академия Естествознания»

(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 является в большей степени вывеской, чем фактором, приносящим пользу в работе организации. Дополнительное обеспечение, необходимое для проверки процесса, должно являться естественным побочным продуктом процесса управления проектом.

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

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

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

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

студент-магистрант 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.

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

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

Рис. 1.26.

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

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

Таблица 1.8

Потребности заинтересованных сторон

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

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

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

Особое внимание обращается на качество производимой продукции, под которой в соответствии с ИСО 9000:2000 подразумеваются: услуги, программные средства, технические средства, перерабатываемые материалы.

На этапе оценки процессов предприятия выделяем объекты оценки (табл. 1.9).

В данной модели содержится следующее:

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

Объекты и переменные оценки

Объекты оценки	Переменные оценки
Уровень сопроводительного сервиса при эксплуатации продукции	Структура сопроводительного сервиса. Наличие нормативной документации по сопроводительному сервису. Полнота и качество нормативной документации по сервису. Наличие процедуры определения ресурсов для сервиса. Наличие процедуры оценки качества сопроводительного сервиса. Наличие процедур корректирующих и предупредительных действий по сопроводительному сервису
Обеспечение своевременности поставок	Наличие контрактов на поставку и их качество. Наличие графика поставок материалов и комплектующих. Наличие процедуры оценки качества поставок. Наличие процедуры корректирующих и предупредительных мер по поставкам. Качественный уровень персонала службы снабжения
Безопасность эксплуатации производимых изделий	Наличие расчетных обоснований безопасности конструкции изделия. Наличие процедур контроля безопасности при изготовлении продукции. Наличие нормативной документации по испытаниям изделия. Предоставление потребителям гарантий безопасности изделий
Ресурсы и условия их использования	Наличие нормативной документации по определению потребности в ресурсах для изделия. Степень фактической обеспеченности ресурсами всех видов. Качество используемых ресурсов

Подход к измерению процесса показан на рис. 1.27.

При применении этого подхода на этапе измерения эффективности организация должна:

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

Рис. 1.27.

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

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

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

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

Зрелость выбранного процесса устанавливается как степень соответствия его заявленной зрелости фактической зрелости для того, чтобы определить риски, связанные с производством продукта на базе этого процесса. Заявленная зрелость может быть основана на результатах прежних аналогичных оценок процесса или на результатах аттестации. Как видно, начальным является состояние нестабильности предприятия, характеризуемое дисбалансом его основных целей и наличием неполных процессов. Переход на следующий качественный уровень определяется управлением в виде соответствия стандарту на основе информационной системы (стандарта управления) MRP II (Manufacturing Resource Planning - планирование ресурсов производства).

Последовательный переход до состояния «мировой лидер» обеспечивается путем использования системы качества на базе моделей TQM с информационной поддержкой ERP II (планирование ресурсов предприятия, взаимоотношениями с поставщиками) [ 15, 26, 27].

Для оценки процессов СМК необходимо иметь эталонную модель.

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

Рис. 1.28.

тесно взаимосвязанный с семейством стандартов ИСО 9000:2000, предоставляет хорошую методологическую базу для оценивания процессов.

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

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

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

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

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

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

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

Уровень 0: Неполный процесс. Клиенты и их требования не определены. Методы работы не определены и не документированы. Деятельность с потребителями неизвестна. Результаты не управляемы.

Уровень 1: Выполняемый процесс. Клиенты определены и их требования известны и преобразованы в критерии результативности. Методы работы стандартизированы на основе общих процедур. Управление результатами производится с помощью послепроцес- сного контроля.

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

Уровень 3: Устоявшийся процесс. Имеется тенденция роста удовлетворенности потребителей. Проводятся внутренние аудиты для проверки используемых методов. Внешняя результативность воспроизводима. Внутренняя результативность определена и реализуется.

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

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

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

Не обладает. От 0 до 15% - доказательство того, что оцениваемый процесс обладает заданной характеристикой, отсутствует либо недостаточно.

Обладает частично. От 16 до 50% - доказательство разумного систематического подхода к заданной характеристике и того, что оцениваемый процесс обладает ею в некоторой степени.

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

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

Адаптированные показатели обладания характеристиками для процессов промышленного предприятия приведены в табл. 1.10, а рейтинги зрелости процессов - в табл. 1.11 }