Усовершенствование процесса получения крекинг-газа пиролизом нафты
Корчагина Татьяна Константиновна,
кандидат химических наук, доцент,
Оноприенко Дарья Андреевна,
студент-магистрант 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.
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.1 );
б) по определению требований к продукции (п. 7.2.1 );
в) по мониторингу и измерению процессов (п. 8.2.3 ) и продукции (п. 8.2.4 );
В результате работы команды руководителей-экспертов появляется довольно обширный список процессов, нуждающихся в улучшении. Для уменьшений перечня таких процессов следует обратиться к экономическим данным.
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. Идентификация причин главного несоответствия (дефекта).
3.3.1. Использование экспертного метода.
При применении экспертного метода члены команды путем проведения мозговых атак (штурма, осады) генерируют множество возможных причин ранее определенного главного несоответствия (дефекта). При этом можно использовать мнемонический прием 4М, ..., 6М, рекомендуемый для стратификации данных, согласно которому каждая мозговая атака должна быть посвящена определению перечня причин по следующим факторам :
В результате такой работы появляется диаграмма Исикавы, обычно включающая в себя до 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.8.
Этап 3.7 эквивалентен третьей фазе (Check) цикла улучшения PDCA Деминга.
3.8. Разработка стандартизованной процедуры осуществления улучшения.
Цель этапа - включить новый улучшенный процесс в практическую работу организации. Разработка и утверждение высшим руководством организации стандартизованной процедуры нового улучшенного процесса будет являться превентивной мерой против возвращения к старым приемам (навыкам) работы. При выполнении работ на данном этапе важно принять во внимание следующие аспекты:
В результате выполнения этапа 3.8 в организации появляется стандартизованная процедура осуществления улучшенного процесса, доведенная до сведения персонала либо в виде стандарта организации (документированной процедуры), либо путем обучения и тренинга персонала на рабочих местах.
IV . Полномасштабное внедрение улучшенного процесса и выполнение стандартизованной процедуры.
Четвертая стадия очередной итерации процесса постоянного улучшения включает в себя выполнение пяти рассмотренных ниже этапов работы.
4.1. Определение перечня подразделений (технологических линий, станков, оборудования, рабочих мест), в которых предстоит осуществить полномасштабное внедрение стандартизованной процедуры.
Если запланированное и осуществленное в малом масштабе усовершенствование привело к необходимым улучшениям показателей выполнения деятельности процесса, то полученные результаты и стандартизованные процедуры надо внедрить в практическую деятельность организации в полном масштабе.
На данном этапе члены команды, занимавшиеся усовершенствованием процесса первоначально в малом масштабе, проводят работу с целью определить наиболее полный перечень подразделений организации, технологических процессов и линий, аппаратуры, станков, оборудования и рабочих мест, на которых предстоит полномасштабное внедрение стандартизованной процедуры выполнения улучшенного процесса. Этот перечень должен быть дополнен планом мероприятий по полномасштабному внедрению результатов работы команды с определением источников ресурсов, за счет которых будут приобретаться необходимые комплектующие узлы, детали и оплачиваться работы по их монтажу в конкретных подразделениях.
4.2. Приобретение необходимых комплектующих узлов, деталей и их монтаж.
После утверждения плана мероприятий высшим руководством организации соответствующие службы осуществляют размещение заказов и закупку, а затем и монтаж приобретенных комплектующих узлов, деталей на существующих аппаратах и оборудовании организации.
4.3. Обучение персонала работе в соответствии с новыми требованиями стандартизованной процедуры.
Специалисты и операторы, осуществлявшие подпроцессы и операции улучшенного процесса при первоначальном его внедрении в малом масштабе, на данном этапе привлекаются для проведения обучения и тренинга на рабочих местах тех специалистов и операторов, которым предстоит работа по контролю и управлению подпроцессами и операциями улучшенного процесса после его полномасштабного внедрения. Рекомендуется предоставление возможности специалистам и операторам, которым предстоит участвовать в полномасштабном внедрении улучшенного процесса, пройти стажировку на рабочих местах на том участке, где уже был внедрен (в малом масштабе) улучшенный процесс.
4.4. Полномасштабное внедрение стандартизованной процедуры во всех подразделениях.
После монтажа приобретенных комплектующих, деталей, оборудования на имеющихся линиях и аппаратах, а также по завершении обучения и тренинга на рабочих местах специалистов и операторов приступают к полномасштабному внедрению стандартизованной процедуры выполнения улучшенного процесса в соответствии с утвержденным планом мероприятий. При этом внедрение стандартизованной процедуры происходит не одномоментно.
Сначала внедряют улучшенный процесс в том подразделении, где эти работы было запланировано выполнить в первую очередь. Затем, по мере готовности, происходит внедрение улучшенного процесса и в других подразделениях организации в соответствии с имеющимся планом и финансовыми возможностями.
4.5. Периодический контроль выполнения требований стандартизованной процедуры с целью предотвращения возврата к старым методам и приемам работы.
После завершения работ по полномасштабному внедрению улучшенного процесса следует помнить, что людям свойственно возвращение к старым методам и приемам работы. Поэтому руководителям подразделений, в которых внедрены новые процедуры осуществления улучшенного процесса, следует рекомендовать:
1) после внедрения нового улучшенного процесса необходимо удостовериться в том, что
2) периодически проводите мониторинг и контроль работы персонала для предотвращения возможного возврата к старым методам и приемам выполнения подпроцессов и операций улучшенного процесса;
3) насколько возможно чаще и полнее получайте информацию и поддерживайте связь с работниками, выполняющими измерения, контроль и управление подпроцессами и операциями улучшенного процесса;
4) документируйте предпринимаемые корректирующие и предупреждающие действия, направленные на снижение изменчивости процесса.
После завершения четвертой стадии в организации должно быть достигнуто следующее:
В заключение следует отметить, что при осуществлении в организации процесса постоянного улучшения рекомендуется:
3) сертифицировать улучшенный процесс (верифицировать, осуществлять валидацию, утверждать результаты работы команды).
После завершения очередной итерации процесса постоянного улучшения применительно к ранее самому дефектоносному (критическому) процессу необходимо (рис. 1) выбрать новый процесс, подлежащий усовершенствованию, и вновь осуществить все четыре стадии, регулярно повторяемые на каждой очередной итерации процесса постоянного улучшения.
Рецензенты:
Коллектив авторов Harvard Business School Press
Глава из книги «Руководство по улучшению бизнес-процессов »
Издательство «Альпина Паблишер»
Улучшение бизнес-процессов - совокупность методов и подходов, которые дают руководителям компании возможность повысить эффективность ее работы. Как следует из наименования процедуры, которую также иногда называют менеджментом бизнес-процессов, цель ее - улучшение бизнес-процессов, которое помогает сделать их более эффективными. В организациях, уделяющих внимание совершенствованию бизнес-процессов:
Улучшение бизнес-процессов - инструмент, который может быть использован в организации на любом уровне: и менеджером, собравшимся изменить сравнительно несложный процесс внутри своего отдела, и представителем высшего руководства, цель которого - внедрить новую инициативу в масштабах компании, чтобы улучшить продуктивность работы организации в целом.
Возможно, ваша организация уже осуществляет широкомасштабную программу совершенствования бизнес-процессов, в которой обязаны участвовать руководители всех уровней. Если дела обстоят именно так, возможно, вы захотите вкратце ознакомиться с некоторыми подобными масштабными программами. Примеры их вы найдете в таблице «Формальные методики и стандарты совершенствования бизнес-процессов».
Таблица 1. Формальные методики и стандарты совершенствования бизнес-процессов
| Название | Описание |
|---|---|
| Шесть сигм (Six Sigma) | Строгая, основанная на фактах методика, позволяющая выявлять и устранять недостатки в любых процессах. Направлена на всемерное повышение эффективности, надежности и потребительской ценности товаров и услуг. Методика «Шесть сигм» была разработана в 1980-е годы в компании Motorola, когда ее руководство осознало, что в ходе использования продукты с минимумом изначальных недочетов отказывают значительно реже. Греческая буква сигма обозначает отклонение от стандарта. |
| Всеобщее управление качеством (Total Quality Management, TQM) | Стратегия менеджмента, цель которой - внедрение заботы о качестве в каждый процесс, осуществляемый в организации, и всемерное поощрение действий сотрудников, направленных на повышение удовлетворенности клиентов и снижение издержек. Активно внедрялась в Японии после Второй мировой войны американским статистиком и преподавателем Эдвардом Демингом. Позднее Джозеф Джуран расширил концепцию управления качеством, отойдя от узкостатистического толкования и уделив максимум внимания человеческой составляющей. |
| ISO 9000 | Серия стандартов систем управления качеством (ISO). Эти стандарты не гарантируют качество конечного товара или услуги - скорее они удостоверяют тот факт, что компания использует сертифицированные бизнес-процессы. Стандарты ISO 9000 находятся в ведении структур, отвечающих за аккредитацию и сертификацию. |
| Реинжиниринг бизнес-процессов (BPR) | Методика менеджмента, обеспечивающая радикальное совершенствование рабочих процессов как внутри отдельной организации, так и между организациями с целью значительного повышения эффективности деятельности. Стремительный взлет этой методики относится к началу 1990-х годов, когда Майкл Хаммер и Джеймс Чампи опубликовали свой революционный бестселлер «Реинжиниринг корпорации». |
Существует несколько видов событий, каждое из которых способно послужить спусковым крючком для запуска программы совершенствования (улучшения) бизнес-процессов. В их число входят как объективно неэффективные действия, так и проблемы с достижением намеченных результатов. Вот вам пример. Кара, менеджер регионального офиса продаж крупной компании, выпускающей потребительские товары, обнаруживает, что его показатели продаж на 5% ниже, чем у офисов в других регионах. Ее сотрудники работают изо всех сил, но не могут добиться решения поставленных перед ними задач. Кара решает изучить основные бизнес-процессы - то, как ее сотрудники работают с потенциальными покупателями и открывают клиентские счета. Ее цель - разобраться, можно ли изменить какие-то из этих процессов так, чтобы увеличить показатели продаж.
Значительные изменения на рынке также могут стать двигателем совершенствования бизнес-процессов. Изменения в бизнес-ситуации могут принимать самые разнообразные формы, от появления новых технологий до смены потребительских предпочтений и прихода конкурентов. К примеру, менеджер по персоналу Маркус заинтригован возможностями, которые открывает для бизнеса Интернет. Он осознает, что, если дать сотрудникам возможность самостоятельно выбирать через Интернет условия обслуживания по медицинской страховке на предстоящий год, это поможет сэкономить время и деньги. Ведь ранее для внесения изменений им нужно было лично встречаться с менеджерами по персоналу. Поэтому Маркус решил усовершенствовать методы работы кадровой службы, развивая свои идеи по использованию Интернета для повышения эффективности максимально возможного числа бизнес-процессов.
Не так давно Пол устроился на работу менеджером в компанию Pedal Power, организующую велосипедные туры. Девятью месяцами ранее компания начала предоставлять новую услугу: сотрудники с помощью электронных рассылок стали сообщать клиентам о новых турах и предлагать скачать информацию о текущей программе туров с подробными пояснениями.
Поначалу клиенты были довольны новой услугой. Но в последнее время многие стали жаловаться, что получают устаревшую информацию о поездках. Пол понимает, что проблема кроется в процессах обновления информации и организации рассылки. Но он не понимает, как решить эту проблему.
Вот что предложил бы ему наш эксперт.
Хотя работа Пола проходит в виртуальном пространстве, он может относиться к ней как к традиционному производству. Это поможет ему инициировать процедуру улучшения бизнес-процессов. Для начала ему следует собрать команду, которая проанализирует существующий бизнес-процесс, а затем придумает, как его реорганизовать, исключив текущие недочеты. На следующем этапе команде нужно будет привлечь ресурсы, необходимые для внедрения в практику обновленного бизнес-процесса (это может быть, к примеру, дополнительный персонал или новое оборудование). Затем команда Пола может внедрить пилотный проект, проверить, не осталось ли еще каких-либо проблем, - и лишь затем использовать его в полном объеме. Но даже после того, как новый процесс станет стандартной процедурой, команде нужно будет продолжать отслеживать его эффективность, при необходимости внося дополнительные изменения.
Хорошо организованная программа совершенствования бизнес-процессов может дать вашей организации много значимых результатов. Например, понять, насколько эффективно ваша команда удовлетворяет потребности клиентов и других подразделений компании. Способствовать пересмотру стратегии привлечения персонала с целью улучшить знания и навыки, повысить профессиональный уровень коллектива. Помочь вашей компании сэкономить время и деньги, упростив сложные и дорогостоящие процедуры. Кроме того, она может открыть вам глаза на существование совершенно новых бизнес-процессов, которые помогут вашей фирме оказывать максимально качественные услуги клиентам, в то же время снизив издержки.
Качественный менеджмент бизнес-процессов способен обеспечить значительные преимущества любой команде или организации. Однако, чтобы их добиться, необходимо применять системный подход к совершенствованию бизнес-процессов. Специалисты рекомендуют осуществлять менеджмент сравнительно сложных бизнес-процессов, используя шести-ступенчатую схему:
Разумеется, если вы собираетесь лишь несколько видоизменить какой-нибудь из простых бизнес-процессов внутри вашего подразделения, нет нужды скрупулезно реализовывать каждый из шести шагов. Достаточно просто по-быстрому обдумать каждый из них. Предположим, вы хотите упростить процесс принятия решений в своем отделе. До сих пор в течение недели до принятия решения вы беседовали с каждым членом коллектива. Но после того, как в отделе прибавилось сотрудников, эта процедура стала слишком долгой и громоздкой. Подумав, вы предлагаете изменить ее и еженедельно проводить встречи всех членов своей команды, на которых бы обсуждались ключевые вопросы. В результате предпринятых изменений вы сэкономите время, которое потратите на более продуктивную деятельность.
Чтобы составить план изменения бизнес-процессов, вам необходимо будет предпринять следующие шаги:
Чтобы составить план улучшения бизнес-процессов, для начала следует решить, действительно ли организация процессов в вашей компании нуждается в улучшении. Ответ на этот вопрос будет положительным, если вы наблюдаете ряд характерных симптомов, включая следующие:
Вполне возможно, вы, как и большинство менеджеров, наблюдаете одновременное проявление целого ряда симптомов возникших проблем. Это позволяет предположить, что вашей организации будет выгодно заняться совершенствованием целого ряда бизнес-процессов. К примеру, Джо, руководивший региональным офисом компании, предлагающей финансовые услуги, обнаружил многочисленные жалобы клиентов на то, что при заполнении заявки на кредит им приходится несколько раз указывать одну и ту же личную информацию. Кроме того, несмотря на высокий профессионализм сотрудников Джо, бизнес его офиса, исходя из количества новых клиентских счетов, открытых в течение квартала, рос медленнее, чем у других региональных офисов.
Когда у вас складывается впечатление, что в улучшении нуждаются сразу несколько процессов, как решить, каким из них следует заняться в первую очередь? Составьте матрицу выбора процессов, в которой вы сможете оценить каждый из них в соответствии с выбранными критериями, - например, насколько легко будет изменить тот или иной бизнес-процесс и много ли проблем создает для клиентов его неотрегулированность. Каждый проблемный процесс оцените по шкале от 1 до 5, где 5 будет максимальной оценкой, а 1 соответственно - самой низкой. Пример такого выбора вы можете наблюдать в таблице «Матрица выбора процессов Джо».
Таблица 2. Матрица выбора процессов Джо
Оценив каждый из процессов, подведите итог. Наиболее высокий рейтинг означает, что именно этим процессом необходимо заняться в первую очередь. В случае с Джо онв итоге решил сосредоточиться на открытии новых счетов.
Более подробную информацию см. в разделе «Расставляем приоритеты при совершенствовании бизнес-процессов: полезные советы».
Расставляем приоритеты при совершенствовании бизнес-процессов: полезные советы
Решив, какой именно процесс будет подвергнут перестройке, определитесь с масштабами, целями и графиком изменений. Масштабы изменений определяют, что именно будет затронуто переменами, а что нет. Например, чтобы улучшить механизм открытия новых счетов, Джо решил изменить способ взаимодействия его сотрудников и технологий. Он предпочел по возможности ни менять работу, выполняемую сотрудниками, ни задействовать новые технологии. Определите, в какой степени предстоящее видоизменение бизнес-процессов соответствует целям вашей организации. Ясно обозначьте, каким образом данный конкретный процесс связан с другими, происходящими в ней, и как он влияет на основных заинтересованных лиц, таких как клиенты и поставщики компании. Выразите желательные улучшения в цифрах. К примеру, Джо утверждает, что усовершенствование процесса открытия счетов поможет его компании достичь стратегической цели - эффективнее и быстрее обслуживать клиентов. Процедура открытия счетов напрямую влияет на степень удовлетворенности клиентов и связана с другими процессами, осуществляемыми в ходе рассмотрения заявок на кредиты, в том числе оценкой кредитных историй соискателей. Джо описывает желаемое улучшение следующим образом: «Чтобы открыть у нас счет, клиенты должны предоставлять личную финансовую информацию только один раз». Чтобы определиться с графиком изменений, выделите ключевые задачи, которые необходимо будет решить в ходе усовершенствования проблемного бизнес-процесса, и приблизительно оцените, в какие сроки это можно будет сделать. Например, для Джо ключевыми этапами должны стать составление в течение двух месяцев схемы нового процесса открытия счетов и пробный запуск обновленной процедуры в конце третьего квартала.
Решите, кто будет реализовывать проект. Команда должна состоять из следующих сотрудников:
Установите базовые правила работы для команды, занятой усовершенствованием. Например, определите, как часто вы будете встречаться для обсуждения прогресса в ваших начинаниях и решения возникших проблем. Кто будет отвечать за конкретные аспекты работы? Как члены коллектива будут делиться друг с другом информацией и разрешать возникающие конфликты?
При необходимости привлеките к работе по улучшению бизнес-процесса вашего собственного руководителя, подготовив для него убедительное описание проекта, безоговорочно доказывающее его ценность для компании. Наконец, обсудите со своим руководителем, в какие сроки и в какой форме члены команды должны отчитываться о ходе работы.
(The Software Engineering Institute’s Capability Maturity Model, SEI СММ) - широко.
известный способ оценки зрелости процесса создания ПО . СММ является популярным методом оценки зрелости процесса создания ПО для организаций во многих различных областях. Данное приложение предполагает базовое понимание СММ. Здесь проводится обсуждение текущего состояния СММ, как это обычно практикуется в промышленности. Основы определения зрелости процесса создания ПО описываются в книге «Managing the Software Process» .
Ключевые моменты.
А Модель технологической зрелости (Capability Maturity Model, СММ) является отличной точкой зрения для оценки схемы процесса, представленного в данной книге. Надлежащим образом реализованный и используемый по убеждению, этот процесс может достигать 3 или 4 уровня зрелости.
А Реальным показателем зрелости процесса является предсказуемость его результатов и хода выполнения, что оказывает положительное влияние на последующие виды деятельности.
А Наличие зрелого процесса оказывается более важным, чем простое прохождение проверок.
А Зрелому процессу не страшны внезапные проверки. Если организация говорит, что она делает, и делает, что говорит, нет никакой необходимости специально готовиться к проверкам.
Е.1 ОБЩИЙ ОБЗОР СММ.
В СММ определены пять уровней зрелости процесса создания ПО, основанных на том, какие конкретные «ключевые» области процесса (Key Process Area, КРА) поддерживаются организацией. Уровень 1 (самый низший) соответствует организации с незрелым или неописанным.
процессом. Уровень 2 (воспроизводимый), уровень 3 (определенный), уровень 4 (управляемый) и уровень 5 (оптимизированный) описывают организации с более высокими уровнями зрелости процесса создания ПО. КРА, соответствующую каждому из этих уровней, можно охарактеризовать следующим образом:.
■ КРА уровня 2: управление требованиями, планирование проекта по созданию ПО, отслеживание и контроль за выполнением проекта по созданию ПО, обеспечение качества ПО, управление конфигурацией ПО.
■ КРА уровня 3: большое внимание процессу организации, определение процесса организации, программа обучения, интегрированное управление созданием ПО, разработка программных продуктов, координация между группами, визуальные проверки.
ш КРА уровня 4: измерение и анализ параметров процесса, управление качеством, предотвращение появления дефектов.
■ КРА уровня 5: нововведения в технологию, управление изменением процесса.
Целью большинства организаций является достижение процесса уровня 3. Для определения зрелости организации используется оценка возможностей ПО (Software Capability Evaluation, SCE). SCE позволяет выяснить, действительно ли организация «говорит то, что она делает, и делает то, что говорит», посредством оценки процесса создания ПО, используемого в данной организации (обычно в виде отдельных положений, определяющих политику), и практики выполнения проектов. Политика организации - «говорит, что она делает» - и реализация проектов - «делает то, что говорит» - оцениваются по соответствующей КРА-схеме. Процесс оценки не является совершенным, однако он может служить хорошим относительным показателем зрелости процесса создания ПО.
Для типичной SCE в качестве одной из частей тщательной проверки применяется SEI Maturity Questionnaire («Вопросник для определения зрелости») . Это определение зрелости включает в себя подробный анализ, интервью и другие формы оценки. Данный вопросник, вообще говоря, используется в качестве отправной точки для создания контекста, в котором будет производиться оценка.
Существует большое число различных оценок распределения организаций, занимающихся созданием ПО, по этим пяти уровням. В таблице Е.1 дается приблизительное распределение для индустрии ПО в 1995 г.
Одним из главных недостатков SEI СММ является то, что КРА ориентируются прежде всего на документальные рабочие продукты традиционного процесса (такие, как проект, требования и документы, определяющие соответствие требованиям), а также на контракты, контракты субподряда, планы и отчеты. Очень немногие КРА реально обращаются к изменяющимся рабочим продуктам, касающимся разработки (модели требований, проектные модели, исходный код или выполняемый код), к.
уровню автоматизации процесса, обеспечиваемого средой, или к процессу создания архитектуры ПО. Другими словами, большая часть из моих 10 основных принципов современного процесса не учитывается на тех уровнях, которым она соответствует. Другим недостатком является присущее СММ рассмотрение управления конфигурацией и обеспечения качества как дисциплин, независимых от остальных видов деятельности в рамках процесса, а не как их неотъемлемой части.
Таблица Е.1.
Распределение по уровням зрелости в индустрии ПО
На практике реальным показателем зрелости процесса является уровень предсказуемости хода выполнения проекта. Попытка поставить в соответствие ход выполнения проекта пяти уровням зрелости СММ может выглядеть следующим образом:.
■ Уровень 1 соответствует случайному (непредсказуемому) выполнению.
■ Уровень 2 позволяет достигать воспроизводимого выполнения от проекта к проекту.
■ Уровень 3 демонстрирует улучшение выполнения следующих друг за другом проектов в терминах затрат, сроков или качества.
■ Уровень 4 свидетельствует о таком выполнении проектов, при котором для следующих друг за другом проектов происходит существенное улучшение либо одного из параметров выполнения процесса, либо нескольких параметров (например, затрат и качества).
■ Уровень 5 соответствует идеальному выполнению следующих друг за другом проектов или существенному улучшению сразу всех параметров. Организации уровня 5 обычно занимают очень узкую нишу.
На рис. Е.1 показано ожидаемое выполнение следующих один за другим проектов в организациях с различным уровнем зрелости.
Многие организации могут делать вид, что их процесс соответствует уровню 3. Соответственно, процесс уровня 3 необязательно является хорошим процессом. С другой стороны, по-настоящему хороший процесс всегда с легкостью получит рейтинг, соответствующий уровню 3. Мой практический опыт, полученный при оценке десятков проектов по созданию ПО и определению возможностей ПО, дал мне понимание некоторых других показателей действительного процесса:
Рис. Е.1. Ожидаемое выполнение проектов для различных уровней зрелости СММ.
■ Объективное понимание текущей зрелости.
■ Объективное понимание выполнения проекта в терминах затрат и сроков, поддающихся количественному выражению.
■ Реальное улучшение выполнения проекта.
■ Минимальное время, необходимое для подготовки к проведению оценки.
Зрелая организация и зрелые проекты понимают процесс и следуют ему. Им не приходится тратить время на подготовку к проверке. Если вы думаете, что ваша организация соответствует уровню 3, то ответьте на такой вопрос: сможет ли она выдержать внезапную проверку?.
Е.2 ПРАКТИЧЕСКОЕ УЛУЧШЕНИЕ ПРОЦЕССА.
В этом разделе приводятся некоторые предварительные размышления по общим вопросам улучшения процесса. Моей задачей является установить правильный баланс между надеждами и опасениями относительно тех перспектив, которые связаны с улучшением процесса.
■ Зрелость процесса. Соответствие схемам определения качества процесса, например SEI СММ, необязательно приводит к получению качественного продукта. Однако действительно высококачественный процесс будет оценен как зрелый. Один из основных недостатков большинства схем процессов состоит в том, что они задают статически определенную программу подтверждения качества как чей-то независимый вид деятельности, вместо того чтобы динамически интегрировать обеспечение качества во все виды деятельности.
■ Стоимость зрелого процесса. Зрелый процесс не требует большого количества денег. Напротив, он позволяет экономить деньги в долговременном смысле. Поскольку улучшение незрелого проекта всегда приводит к изменению структуры затрат, в организациях обычно обращается внимание на кратковременные затраты, связанные с улучшением процесса. Важным моментом здесь является то, что внушение мысли об улучшении процесса для тех проектов, которые уже находятся в стадии выполнения и в которых преобладает краткосрочный подход к определению затрат, является делом очень трудным. Однако необходимость в улучшении процесса легко внушить тем организациям, которые преследуют‘долговременные цели в бизнесе, и для тех долгосрочных проектов, которые все еще находятся в стадии планирования.
■ Метрики ПО. Объективные измерения, необходимые для оценки качества программного продукта и прогресса в работе, - это два взгляда под различными углами зрения на создание ПО. Разработчики архитектуры больше интересуются показателями качества, в то время как менеджерам обычно нужны показатели прогресса. Успех любого процесса создания ПО, в котором значения метрик собираются вручную, будет ограниченным. Большинство самых важных метрик ПО - это простые, объективные измерения того, каким образом продукт/проект изменяется с различных точек зрения. Измерение абсолютных значений обычно менее важно, чем измерение относительных изменений в зависимости от времени. Из-за динамичного характера проектов по созданию ПО эти измерения должны быть доступны в любое время, необходима возможность их адаптации для ■ различных составных частей постоянно изменяющегося продукта (подсистемы, версии, компонента, команды), и они должны содержаться в таком виде, чтобы можно было оценить тенденции (первую и вторую производные). Постоянная доступность была достигнута на практике только тогда, когда метрики стали поддерживаться в онлайновом режиме в качестве автоматизированного побочного продукта среды разработки.
■ Адаптация процесса. Различные виды деятельности по созданию ПО требуют разных процессов. Имеются некоторые универсальные приемы и способы, но существуют также зависящие от ситуации различия в способах, приоритетах, церемонии и в том, на что обращается основное внимание. Разные ситуации при разработке ПО определяют различные требования, которые охватывают целый диапазон процессов. Внутренний процесс организации для создания некоторого продукта не будет в точности совпадать с процессом, который используется в проектах по разработке больших операционных систем по контракту со сторонним заказчиком.
■ Процесс в сравнении с методом. Процесс управления проектом имеет дело с иными понятиями, нежели технический метод. Первый характеризуется итерационной разработкой, основанными на демонстрациях оценками и управлением рисками; второй - объектно-ориентированными методами, подходами к архитектуре и UML-представлениями. Плохое управление процессом, вероятно, никогда не сможет быть спасено с помощью хорошего метода, а вот хорошее управление процессом, скорее всего, приведет к успеху при использовании большинства технических методов. Понятно, что одни методы лучше других. Результат, который получается с помощью хорошего метода разработки, совмещенного с хорошим процессом управлением, - абсолютен. Это - основная цель.
Е.З ВОПРОСНИК ДЛЯ ОПРЕДЕЛЕНИЯ ЗРЕЛОСТИ.
Ниже обсуждается подход к процессу, представленному в настоящей книге, с точки зрения SEI СММ. «Вопросник для определения зрелости» SEI использовался мной в качестве сценария для оценки степени завершенности подхода к процессу с общепринятой точки зрения на зрелость процесса. Каждый цитируемый вопрос выделяется курсивом, а за ним следует мой ответ со ссылками на материалы, различные виды работ и контрольные точки процесса.
В некоторых ответах, например, касающихся вопросов обучения, схема процесса не предусматривает какого-либо конкретного подхода. Такие ответы являются специфичными для каждой организации; это означает, что для отдельной организации потребуется свой собственный механизм, определяемый ее внутренней практикой и культурой.
Управление требованиями, уровень 2.
Используются ли ваши системные требования, относящиеся к ПО, в качестве базы для разработки и управления проектом?.
А Требования к ПО содержатся в документе с общей концепцией и в модели вариантов использования. Каждой итерации соответствуют спецификации версии, в которых определяются цели для промежуточных контрольных точек. Все эти рабочие продукты входят в базовую версию ПО и подпадают под процесс управления изменениями.
Вносятся ли необходимые уточнения в планы, рабочие материалы и виды деятельности по мере изменения требований, относящихся к ПО?.
▲ При итерационной разработке каждая новая итерация сопровождается новыми спецификациями версии и соответствующим обновлением технических рабочих продуктов. Назначением запросов на внесение изменений в ПО (SCO) типа 3 и является обращение к необходимым изменениям, вызванным изменением требований.
Следует ли проект зафиксированной в письменном виде политике данной организации по управлению системными требованиями, относящимися к ПО?.
А Политика организации должна содержать в явном виде подход к определению и управлению всеми рабочими продуктами проекта, включая комплект рабочих продуктов требований.
Обучался ли персонал, ответственный за управление требованиями, методам управления требованиями?.
Используются ли измерения, проводимые для onpedejieuua состояния, работ, при управлении требованиями (например, общее число изменений требований, которые предложены, открыты, приняты и внесены в базовую версию)?.
A SCO типа 3 должны отслеживаться и учитываться при периодических оценках состояния.
Подвергается ли деятельность по управлению требованиями проверкам на подтверждение качества ПО (Software Quality Assurance, SQA)?.
А Контроль качества является обязанностью всех команд. Независимая организация, которая выполняет тестирование и на которую возлагается основная ответственность за обеспечение качества, просто не рассматривает вопросы управления требованиями; она активно участвует в создании спецификаций версии и в обеспечении ее соответствия набору требований. Совет по контролю за конфигурацией (Configuration Control Board, ССВ) также рассматривает изменения требований, содержащиеся в SCO. Кроме того, комплект рабочих продуктов требований применяется при осуществлении разработки, связанной с усовершенствованием моделей вариантов использования, комплекта рабочих продуктов проектирования, комплекта рабочих продуктов реализации и при демонстрациях комплекта рабочих продуктов внедрения.
Планирование проекта по созданию ПО, уровень 2.
1. Документируются ли оценки (размера, стоимости и сроков) для использования при планировании и для контроля за ходом выполнения проекта?.
A WBS определяет базовую стоимость и план. Бизнес-план и план разработки ПО определяют приблизительный график, содержание итерации и приблизительные размеры с различных точек зрения. Оценки состояния являются механизмом, позволяющим отслеживать прогресс и качество по сравнению с базовыми планами и их уточнениями. На более низких уровнях в SCO отражаются подробные оценки, планы и реальное положение вещей.
А Бизнес-план и план разработки ПО описывают работы самого верхнего уровня, которые необходимо выполнить, и они подписываются менеджером проекта как поручение. В WBS отражаются основные затраты и задачи для всех уровней управления. В SCO также содержатся виды работ и задачи более низкого уровня.
Согласны ли все группы и лица, к которым это имеет отношение, со своими задачами, касающимися проекта по созданию ПО?.
А Декомпозиция работ (WBS) предоставляет механизм для проведения переговоров о поручениях между менеджером проекта и подчиненными ему менеджерами. SCO и ССВ обеспечивают механизм для ведения переговоров о поручениях более низкого уровня.
Следует ли проект политике организации при планировании работ по созданию ПО?.
а Политика должна обеспечивать организационную основу для планирования проектов. Инфраструктура организации должна также обеспечивать доступ к предшествующему опыту и к стандартным приемам планирования.
Обеспечено ли планирование проекта по созданию ПО адекватными ресурсами (т.е. финансированием и опытным персоналом)?.
а Менеджер проекта по созданию ПО, ответственный за план, создает его и отвечает за его успех. Этот бизнес-план содержит ожидания и поручения, необходимые организации для определения отдачи от инвестиций по каждому виду работ. Адекватность ресурсов для планирования не определяется политикой. Хорошей отправной точкой может служить цифра 10% - приблизительно такая часть ресурсов проекта должна быть направлена на планирование и работы по управлению. Определение адекватных ресурсов специфично для каждого проекта. Эти оценки должны стать предметом тщательного изучения PRA и должны пересматриваться по достижении всех основных контрольных точек.
Используются ли измерения для определения состояния работ по планированию проекта по созданию ПО (т.е. завершенности этапов работ по планированию) ?.
А Метрики прогресса специально разработаны для того, чтобы обеспечить понимание критичных аспектов плана по сравнению с реальностью (прогресс разработки, прогресс тестирования, критерии оценки, соответствие которым уже достигнуто, реализованные сценарии, разработанные SL0C, число открытых SCO по сравнению с числом закрытых и т.д.).
7. Проверяет ли менеджер проекта работы по планированию проекта по созданию ПО как на регулярной основе, так и при наступлении определенных событий?.
А Оценки состояния гарантируют, что менеджер проекта ответственен за периодические обращения к необходимым показателям управления и оценки рисков. Основные контрольные точки и описания версий являются аналогичным механизмом стимулирования для выполнения оценок при наступлении событий.
Отслеживание и контроль за выполнением проекта по созданию ПО, уровень 2.
Сравнимы ли реальные показатели выполнения проекта (сроки, размеры и затраты) с оценками, содержащимися в планах по созданию ПО?.
А Оценки состояния позволяют сравнивать планируемые результаты с реальными по показателям прогресса. Описания версий дают возможность сравнивать планируемые показатели качества (критерии оценки) с реально полученными результатами. В SCO также содержатся сравнения планируемых и реально полученных результатов для детального управления изменениями.
Предпринимаются ли меры по корректировке в том случае, если реально полученные результаты значительно отличаются от планов проекта по созданию ПО?.
А Невыполненные критерии оценки обязательно должны упоминаться в описаниях версий и учитываться в последующих итерациях. Остальные отклонения от плана отражаются в оценках состояния, где доведение до конца требуется и контролируется.
Согласовываются ли изменения в распределении обязанностей со всеми заинтересованными группами и лицами?.
А Изменения в распределении обязанностей обсуждаются при изменении WBS, планов разработки ПО и оценок состояния. Поручения более низкого уровня также рассматриваются ССВ, отслеживаются по SCO и отражаются в описаниях версий.
Следует ли проект политике организации по отслеживанию и контролю за деятельностью по разработке ПО?.
А Политика организации должна описывать стандартный формат оценок состояния для конкретных наборов тем так, чтобы можно было сравнивать между собой различные проекты.
Существует ли в рамках проекта лицо, на которое возложена особая ответственность за отслеживание продуктов и работ по созданию ПО (например, трудозатрат, сроков и финансирования)?.
А Таким ответственным лицом является менеджер проекта по созданию ПО. Оценки состояния предоставляют механизм, гарантирующий периодические рассмотрения и отчетность в соответствие с основой WBS.
Используются ли измерения для определения состояния работ по отслеживанию и контролю за ПО (например, суммарных трудозатрат на выполнение работ по отслеживанию и контролю)t.
А Затраты, расписанные в WBS, и параметры прогресса обеспечивают механизм для отслеживания состояния работ и предоставляют инструменты и возможность общего контроля над всеми затратами на создание ПО.
Рассматриваются ли работы по отслеживанию и контролю за ходом выполнения проекта вышестоящим руководством на регулярной основе (например, ход выполнения проекта, нерешенные проблемы, риски и необходимые действия)?.
А Это в точности соответствует назначению бизнес-плана (который обновляется при переходах от одной стадии жизненного цикла к другой), оценок состояния и рассмотрениям основных контрольных точек.
Управление субподрядчиками по созданию ПО, уровень 2.
Заключение контрактов субподряда специально не оговаривается в схеме процесса, тем не менее предполагается, что все методы, инструменты и механизмы должны распространяться на всех субподрядчиков для того, чтобы процесс оставался однородным. Если это невозможно или если генеральный подрядчик не в состоянии четко разграничить работы, предназначенные для выполнения субподрядчиком, обладающим зрелым процессом, то привлечения субподрядчиков следует избегать. Для эффективного управления рисками необходимо контролировать количество и сложность внешних взаимодействий организации. Все решения о привлечении субподрядчиков должны быть документированы в бизнес-плане.
Используется ли для выбора субподрядчиков документированная процедура, основанная на их способности к выполнению определенных видов работ?.
А Политика организации должна требовать от всего персонала, работающего над проектом, включая субподрядчиков, следования единому плану разработки. Для участия в выполнении проектов нужно привлекать субподрядчиков, о которых известно, что они имеют процесс, оценка зрелости которого не ниже зрелости процесса, применяемого в головной организации по выполнению проекта. (Другими словами, организация с уровнем 3 не должна привлекать субподрядчика с уровнем 2.).
Вносятся ли изменения в контракты субподряда с обоюдного согласия основного подрядчика и субподрядчиков?.
А Здравый смысл подсказывает, что это всегда должно быть именно так.
Производится ли регулярный обмен технической информацией с субподрядчиками?.
А Субподрядчики, следующие одному и тому же плану разработки, будут участвовать в одних и тех же обменах технической информацией, основных контрольных точках и оценках состояния.
Отслеживаются ли результаты и ход выполнения работ по созданию ПО субподрядчиками в соответствии с тем, что им поручено?.
А Работа субподрядчиков, следующих одному и тому же плану разработки, должна контролироваться в соответствии с тем, что им поручено, точно так же, как это делается у генерального подрядчика.
Следует ли проект политике организации по работе с субподрядчиками?.
А Документы, определяющие политику, требуют, чтобы субподрядчики использовали тот же процесс, который применяется генеральным подрядчиком.
Обучаются ли лица, ответственные за управление субподрядом, управлять субподрядами по созданию ПО?.
А Обучение зависит от конкретной организации.
Используются ли измерения состояния работ для управления субподрядом по созданию ПО (например, соответствие срокам с учетом дат планируемых поставок и трудозатрат, израсходованных на управление субподрядом)?.
А Субподрядчики должны управляться точно так же, как генеральный подрядчик.
Проверяет ли менеджер проекта работы по выполнению субподряда по созданию ПО как на регулярной основе, так и при наступлении определенных событий?.
А Менеджер проекта по созданию ПО управляет субподрядчиками точно так же, как и всей остальной командой, работающей над проектом. Все решения, касающиеся поручений субподрядчикам, должны быть документированы в бизнес-плане, который обновляется при переходах от одной стадии жизненного цикла к другой.
Подтверждение качества ПО, уровень 2.
Все виды деятельности и весь персонал вовлекаются в подтверждение качества ПО (SQA). Рекомендуется привлекать независимые команды для проведения оценки с той целью, чтобы работы по оценке качества, такие как тестирование и анализ метрик, могли выполняться параллельно (это дает эффективное использование времени) и независимо (для разнообразия технических точек зрения). Отчетность по вопросам качества распределена по различным командам в рамках организации. Однако для того, чтобы можно было ответить на данные вопросы, работа, выполняемая независимой командой по оценке, должна быть максимально приближена к определению SQA, принятому в СММ.
Планируются ли работы по SQA ?.
А В плане разработки ПО описываются работы по тестированию, определению метрик и деятельность по контролю качества. В WBS содержатся многие детали плана. Спецификации версий также являются механизмом для планирования деятельности по SQA.
Дает ли деятельность по SQA объективное подтверждение того, что продукты и работы по созданию ПО твердо следуют применяемым в данном случае стандартам, процедурам и требованиям?.
А Спецификации версии указывают цели конкретной итерации. Планы разработки ПО определяют стандарты и процедуры выполнения проекта. В спецификациях версии описывается также качество промежуточных продуктов относительно объективных критериев по принципу соответствует/не соответствует. ССВ и SCO гарантируют, что процедуры и стандарты более низкого уровня проверяются и отслеживаются. На автоматизированные инструменты среды (компиляторы, создание документации, управление изменениями) должно быть возложено подтверждение того, что продукты точно соответствуют применяемым в данном случае стандартам.
Передаются ли результаты SQA-рассмотрений и проверок заинтересованным группам и лицам (например, тем, кто выполнял работу, или тем, кто отвечает за ее выполнение)?.
А Все контрольные точки процесса и все виды работ, выполняемой ССВ, являются SQA-рассмотрениями. Промежуточные результаты периодически документируются в описаниях версий. Все SCO рассматриваются ССВ при участии заинтересованных групп.
Рассматриваются ли случаи несоответствия стандартам, которые не региены в рамках проекта, вышестоящим руководством (например, отклонения от применяемых стандартов)?.
а Это является одной из прямых задач утверждения планов разработки и оценок состояния со стороны PRA (Project Review Authority). Регулярные PRA-рассмотрения касаются любых предполагаемых отклонений от политики организации по мере прогресса проекта.
Следует ли проект политике организации по реализации SQA ?.
А Политика организации и планы разработки ПО должны обеспечивать SQA-политикой организацию и проект соответственно.
Обеспечивается ли выполнение работ по SQA адекватными ресурсами (например, финансированием и специально назначенным менеджером, который получает всю информацию о проблемах несоответствия ПО стандартам и принимает по ним решения)?.
А Адекватность ресурсов, выделяемых на SQA, не определяется политикой. Хорошей контрольной цифрой являются 25% от всех работ в рамках проекта, направляемых на работу команды по выполнению оценок (тестирование, оценка, метрики, ССВ). Несмотря на то, что адекватность ресурсов специфична для каждого конкретного проекта, эти оценки, очевидно, должны выполняться под тщательным контролем PRA.
Используются ли измерения для определения затрат и сроков по работам, связанным с SQA (например, объем завершенных работ, трудозатраты и финансовые затраты по сравнению с запланированными)?.
А Основа содержится в WBS, а периодические оценки Состояния позволяют отслеживать реальность по сравнению с планами для всех видов деятельности.
Рассматриваются ли работы по SQA совместно с вышестоящим руководством на регулярной основе?.
А Это одна из основных задач PRA-рассмотрений и PRA-утверждения плана разработки ПО.
Управление конфигурацией ПО, уровень 2.
Все виды деятельности и весь персонал вовлекаются в управление конфигурацией ПО (Software Configuration Management, SCM) точно так же, как в SQA. Независимая команда, выполняющая оценку, принимает на себя основную ответственность за деятельность по управлению конфигурацией, включая сопровождение базы данных SCO, администрирование ССВ и управление базовой версией. Эти виды работ должны выполняться параллельно (для экономии времени) и независимо (для разнообразия технических точек зрения). Вообще говоря, действия по SCM выполняются всеми разработчиками ПО и поддерживаются прежде всего средой разработки ПО. Для ответов на эти вопросы деятельность независимой команды по оценке максимально приближена к определению SCM, принятому в СММ.
Были ли запланированы работы по управлению конфигурацией в рамках проекта?.
А План разработки ПО автоматически должен содержать и поддерживать работы по SCM.
Являлось ли управление конфигурацией средством идентификации, контроля и поставки рабочих продуктов, полученных в результате создания ПО?.
A SCO и все рабочие продукты находятся под управлением конфигурацией.
Следует ли проект зафиксированной процедуре контроля над изменениями, вносимыми в элементы/модули конфигурации?.
a SCO обеспечивают механизм контроля над изменениями в онлайновом режиме, как это записано в политике организации и в плане разработки ПО.
Распространяются ли среди заинтересованных групп и лиц стандартные отчеты по базовым версиям ПО (например, протоколы заседания ССВ, обзор запросов на внесение изменений, отчеты о состоянии)?.
А Оценки состояния, которые содержат в себе результаты работы ССВ в виде стандартных параметров, должны быть доступны для всех заинтересованных сторон и команд проекта.
Следует ли проект политике организации в области реализации работ по управлению конфигурацией ПО?.
А Это обеспечивается политикой организации и планами разработки ПО.
Обучается ли персонал выполнению тех видов деятельности по управлению конфигурацией ПО, за которую он отвечает?.
А Обучение зависит от конкретной организации. Вообще говоря, каждый работающий в организации, занимающейся созданием ПО, сталкивается с управлением конфигурацией в той мере, в какой это определяется средой. Формальные виды деятельности по управлению конфигурацией независимой группы, отвечающей за тестирование, прежде всего касаются административного контроля и составления отчетов.
Используются ли измерения для определения состояния работ по управлению конфигурацией ПО (например, затраты труда и финансов на работы по управлению конфигурацией ПО)?.
A WBS обеспечивает базу, а периодические оценки состояния позволяют определить реальный ход всех работ по сравнению с запланированным.
Производятся ли регулярные проверки на соответствие базовых версий ПО и их документации (например, SCM-группой)?.
А Наиболее частые проверки согласованности базовых версий ПО на основании SCO выполняются ССВ. Описания версий являются проверками общего качества, завершенности и непротиворечивости промежуточных базовых версий, созданных по достижении основных контрольных точек.
Наиболее важные аспекты процесса, используемого в организации, уровень 3.
1. Координируется ли в рамках организации деятельность по разработке и совершенствованию процесса создания ПО (например, специальной группой по разработке процесса создания ПО)?.
А Все планы по разработке и оценке состояния рассматриваются и утверждаются органом, ответственным за процесс разработки ПО (Software Engineering Process Authority, SEPA). Эти механизмы обеспечивают координацию и непротиворечивость в рамках организации.
Регулярно ли оценивается процесс создания ПО в вашей организации?.
A SEPA является ответственным за регулярное проведение оценок, таких как анализ тенденций. Планирование этих оценок и определение их количества должны описываться в приложении к политике организации.
Следует ли ваша организация документированному плану разработки и усовершенствования своего процесса создания ПО?.
A SEPA должен документировать этот план и приложить его к политике организации.
Участвует ли вышестоящее руководство в деятельности, осуществляемой в рамках организации, по разработке и усовершенствованию процесса создания ПО (например, утверждая долгосрочные планы и направляя ресурсы и финансирование)?.
А Степень участия вышестоящего руководства в этой деятельности легко определить по составу группы SEPA и по деталям политики организации. Другим показателем участия руководства является та степень, с которой процесс, используемый в данной организации, поддерживается посредством капиталовложений в автоматизацию.
Несет ли отдельное лицо или группа лиц полную или частичную ответственность за процесс создания ПО, используемый в данной организации (например, группа по разработке процесса создания ПО)?.
А Эта ответственность возлагается на SEPA. Состоит ли данный орган из одного человека, работающего по совместительству, или это команда, занимающаяся только этим вопросом, зависит от специфики организации.
Применяются ли измерения для определения состояния деятельности по разработке и усовершенствованию процесса создания ПО, используемого в данной организации (например, объем трудозатрат на оценку и усовершенствование процесса создания ПО)?.
а Политика организации должна учитывать R0I для SEPA-деятельности и периодически обновляться.
Регулярно ли деятельность по разработке и совершенствованию процесса создания ПО рассматривается вышестоящим руководством?.
А Следует обращаться к генеральному менеджеру организации для утверждения всех текущих изменений в политике организации.
Определение процесса, используемого организацией, уровень 3.
1. Разработан и поддерживается ли вашей организацией стандартный процесс создания ПО?.
А Политика организации определяет стандарт процесса создания ПО, который периодически обновляется.
Занимается ли организация сбором, рассмотрением и обеспечением доступа к информации, касающейся вопросов использования стандартного процесса создания ПО (например, оценок и реальных данных по размерам, трудозатратам и финансовым затратам; данных по производительности; измерений, касающихся качества)?.
A SEPA принимает участие в проведении всех оценок состояния и содержит архив со всей информацией, включая результаты проведенных оценок, планы разработки ПО, данные по выполнению предыдущих проектов, а также другие стандартные инструменты и компоненты организации.
Следует ли организация заданной политике в области разработки и поддержки своего стандартного процесса создания ПО?.
А Политика организации определяет стандарт процесса и его поддержку.
Получают ли сотрудники, которые разрабатывают и поддерживают стандартный процесс создания ПО, используемый в данной организации, необходимую для осуществления этой деятельности подготовку?.
А Обучение зависит от конкретной организации.
Применяются ли измерения для определения состояния деятельности, направленной на описание и поддержку стандартного процесса создания ПО, используемого в данной организации (например, состояния планируемых контрольных точек и затрат на деятельность по определению процесса)?.
А Информация о R0I от деятельности SEPA должна храниться в виде приложения к политике организации.
Подвергаются ли деятельность и промежуточные продукты, связанные с разработкой и поддержкой стандартного процесса создания ПО, используемого в данной организации, SQA-рассмотрениям и проверкам?.
А Деятельность и промежуточные продукты постоянно рассматриваются практиками. Генеральному менеджеру организации следует по мере необходимости собирать соответствующий контролирующий орган с целью проверки того, что дополнительное обеспечение процесса, используемого организацией, является адекватным. SEPA является высшим органом внутри данной организации, ответственным за SQA. Он прекращает все ненужные разговоры до вмешательства генерального менеджера.
Программа обучения, уровень 3.
Планируется ли деятельность по обучению?.
А Обучение зависит от конкретной организации. .
Направленно ли обучение на совершенствование навыков и знаний, необходимых для того, чтобы занимать управленческие и технические посты?.
А Обучение зависит от конкретной организации.
Проходят ли члены групп по разработке и других групп, имеющих отношение к созданию ПО, обучение, необходимое для выполнения своих обязанностей?.
А Обучение зависит от конкретной организации.
Следует ли ваша организация заданной политике для удовлетворения ее собственных нужд в обучении?.
А Обучение зависит от конкретной организации.
Выделяются ли достаточные ресурсы на реализацию программы обучения, принятой в организации (например, финансирование, программный инструментарий, соответствующие условия для обучения)?.
А Обучение зависит от конкретной организации.
Используются ли измерения для определения качества программы обучения?.
А Обучение зависит от конкретной организации.
Проверяется ли вышестоящим руководством деятельность, связанная с программой обучения, на регулярной основе?.
А Обучение зависит от конкретной организации.
Управление интегрированным ПО, уровень 3.
Был ли описанный процесс создания ПО, использованный для выполнения проекта, разработан путем адаптации стандартного процесса создания ПО, применяемого внутри организации?.
А Политика организации определяет обязательные механизмы, точку отсчета и степени свободы для создания процесса данного проекта. Процесс, используемый в проекте, контролируется и утверждается SEPA.
Осуществляется ли планирование и управление процессом в соответствии с описанным для проекта процессом создания ПО?.
А Менеджер проекта по созданию ПО составляет и утверждает план разработки ПО, он же является ответственным за план при периодических PRA-обзорах.
Следует ли проект заданной политике организации, требующей, чтобы он планировался и управлялся с использованием стандартного для данной организации процесса создания ПО?.
А Политика организации - это политика, зафиксированная в виде документов.
Требуется ли обучение тем сотрудникам, перед которыми поставлена задача приспособить стандартный для данной организации процесс создания ПО к описанию процесса создания ПО для нового проекта?.
А Решение проблемы обучения зависит от конкретной организации. Составлять план разработки ПО должен менеджер проекта по созданию ПО.
Используются ли измерения для определения эффективности деятельности по управлению интегрированным ПО (например, частота, причины и размеры затрат на изменение планов)?.
А В проектах используются оценки состояния, включая необходимые метрики, для оценки прогресса и качества. Эти метрики собираются и анализируются SEPA и PRA для определения эффективности и любых требуемых усовершенствований.
Подвергается ли деятельность по управлению проектом и промежуточные продукты, получаемые в результате ее осуществления, SQA-рассмотрению и проверкам?.
а План разработки ПО рассматривается как PRA, так и SEPA (который отвечает за SQA в данной организации).
Разработка программного продукта, уровень 3.
Создаются ли промежуточные программные продукты в соответствии с определенным для данного проекта процессом создания ПО?.
А Менеджер проекта по созданию ПО ответственен за выполнение плана разработки ПО. Любые отклонения от плана или от стандартов (или от того и другого одновременно) периодически рассматриваются при оценке состояния, после чего вносятся соответствующие изменения в последующие итерации или базовые версии продуктов.
Поддерживается ли согласованность промежуточных программных продуктов (например, отражается ли в документации соответствие требований к системе текущим требованиям к ПО, проекту, коду и вариантами тестирования) ?.
А ССВ уделяет постоянное внимание управлению изменениями. Описание версии является механизмом, позволяющим оценивать согласованность и завершенность промежуточных продуктов по достижении основной контрольной точки. Соответствие между комплектами рабочих продуктов разработки (моделями вариантов использования, проектными моделями, исходным кодом и выполняемыми компонентами) поддерживается за счет среды. Степень, с которой информация обобщается или детализируется, зависит от масштаба проекта и требований заинтересованных сторон (например, по вопросам безопасности) и отражается в описаниях версий.
Следует ли проект заданной политике организации при осуществлении деятельности по разработке ПО (например, политике, которая предполагает использование конкретных методов и инструментов для создания и сопровождения программных продуктов)?.
А Политика организации требует определенных видов деятельности и использования некоторой стандартной среды с целью стандартизации методов или инструментов, применяемых в различных проектах. Вопрос об использовании остальных методов и инструментов остается открытым и решается по-своему в каждом конкретном проекте.
Обеспечивается ли выполнение заданий по разработке ПО адекватными ресурсами (например, финансированием, обученным персоналом и необходимым инструментарием)?.
А Адекватность ресурсов, выделяемых на разработку ПО, не определяется политикой. Хорошей контрольной отметкой может служить цифра 50% - именно такую часть всех трудозатрат следует направлять на выполнение задач по разработке ПО: 10% - на описание требований, 15% - на проектирование и 25% - на реализацию компонентов. Определение адекватности ресурсов и персонала специфично для каждого конкретного проекта и должно тщательно изучаться PRA.
Используются ли измерения для определения функциональных возможностей и качества программных продуктов (например, количество, типы и серьезность обнаруженных дефектов)?.
а Основная цель вычисления метрик и их рассмотрения при выполнении оценок состояния заключается в определении прогресса и качества.
Подвергаются ли деятельность и промежуточные продукты деятельности по разработке ПО SQA-рассмотрениям и проверкам (например, выполняется ли необходимое тестирование, определяется ли соответствие требований к системе требованиям к ПО, проекту, коду и вариантам тестирования) ?.
а Все комплекты технических рабочих продуктов изменяются и обновляются при достижении каждой основной контрольной точки. SCO, ССВ и описания версий способствуют привлечению постоянного внимания к наличию такого соответствия.
Координация между группами, уровень 3.
1. Сотрудничают ли группа по разработке ПО и другие группы разработчиков в процессе выполнения проекта с заказчиком для определения системных требований?.
А Общая концепция проекта и спецификации версий входят в сферу ответственности группы по разработке архитектуры ПО. Они обговариваются с заказчиком и изменяются в каждой итерации.
Согласны ли группы разработчиков с возложенными на них обязанностями, которые зафиксированы в общем плане проекта?.
А Планы и поручения содержатся в планах разработки ПО, спецификациях версий и WBS.
Занимаются ли группы разработчиков идентификацией, отслеживанием и разрешением проблем, которые касаются сразу нескольких групп (например, несоответствие графиков, технические риски или проблемы уровня системы в целом)?.
А Демонстрации являются тем механизмом, который обеспечивает продуктивную и реальную координацию на уровне архитектуры. ССВ решает проблемы, касающиеся нескольких групп одновременно, на уровне SCO. Составление правильного графика демонстраций архитектуры позволяет решать проблемы, возникающие при интеграции, на максимально ранних стадиях жизненного цикла. Правильный график также расширяет возможности по разрешению на ранних стадиях важных проблем, касающихся сразу нескольких групп.
Существует ли политика организации, касающаяся создания междисциплинарных групп разработчиков?.
А ССВ, PRA и команды по проведению демонстраций как раз и являются междисциплинарными командами.
Позволяют ли вспомогательные инструменты, используемые различными группами разработчиков, осуществлять эффективное взаимодействие и координацию (например, совместимые текстовые процессоры, базы данных и системы отслеживания проблем)?.
А Стандартная WBS, стандартная среда и база данных SCO позволяют различным группам разработчиков осуществлять координацию в рамках единой схемы. В рамках одного проекта рабочие продукты, создаваемые всеми командами, должны использовать одинаковые нотации, методы и инструменты.
Используются ли измерения для определения состояния деятельности по координации между группами (например, трудозатрат на поддержку одной группой разработчиков ПО других групп)?.
А Вычисление трудозатрат команды по разработке архитектуры позволяет определить стабильность архитектуры. Стабильность архитектуры является хорошим показателем эффективности межгрупповой координации. Поскольку команда по разработке архитектуры является независимой, с четко определенными WBS-элементами, контроль за ее деятельностью проще всего осуществлять с помощью заранее определенного управления и отчетов по метрикам качества при периодических оценках состояния.
7. Рассматривается ли деятельность по координации между группами менеджером проекта на регулярной основе и при наступлении определенных событий?.
А При правильном подходе с упреждающей разработкой архитектуры предполагается, что любые значимые проблемы в межгрупповой координации проявятся на начальных итерациях. Периодические оценки состояния и достижение основных контрольных точек позволяют получать конкретное и объективное понимание состояния межгрупповой координации посредством наблюдения за параметрами архитектуры.
Экспертные оценки, уровень 3.
Схема процесса специально не предполагает наличия экспертных оценок в классическом смысле. Однако существуют некоторые механизмы, цель которых в точности совпадает с классическими экспертными оценками. В число этих механизмов входят демонстрации (экспертные оценки глобальной интеграции), ССВ (экспертные оценки управления изменениями), оценки состояния (экспертные оценки управления) и традиционные экспертные оценки (сквозной контроль кода, инспекции) - все они включаются в планы разработки ПО в рамках данного проекта.
Запланированы ли экспертные оценки?.
А ССВ, оценки состояния и демонстрации следует включать в планы и проводить систематически.
Отслеживается ли деятельность по устранению дефектов, обнаруженных при экспертных оценках, до тех пор, пока они не будут исправлены?.
А Исправление всех дефектов - независимо от того, каким именно способом они были обнаружены, - отслеживается посредством SCO, а все метрики определяются для оценок состояния.
Следует ли проект политике организации в области выполнения экспертных оценок?.
А Политика организации должна предопределять наличие ССВ, демонстраций и оценок состояния. В ней также должно быть указано, что другие формы экспертных оценок описываются в планах разработки ПО в рамках конкретного проекта.
Проходят ли участники экспертных оценок необходимое обучение для выполнения своих обязанностей?.
А Обучение зависит от конкретной организации.
Используются ли измерения для определения состояния деятельности по проведению экспертных оценок (например, количество выполненных оценок, вложенные в экспертные оценки трудозатраты и число промежуточных продуктов, подвергнутых оценкам, по сравнению с планом)?.
▲ ССВ предоставляют широкий набор метрик для управления изменениями. Для описаний версий требуется сбор тех же метрик, что и для демонстраций. SEPA периодически оценивает R0I анализа тенденций для данной организации посредством данных оценки состояния.
6. Подвергаются ли деятельность и промежуточные продукты, связанные с экспертными оценками, SQA-рассмотрениям и проверкам (например, проводятся ли планируемые просмотры, отслеживаются ли окончательные проверки)?.
А Менеджеры проектов по созданию ПО, ССВ и PRA постоянно следят, чтобы эти виды деятельности доводились до конца.
Управление количественными показателями процесса, уровень 4.
Следует ли проект документированному плану управления количественными показателями процесса?.
А В приложении к политике организации должен определяться план улучшения количественных показателей процесса. Оценки состояния позволяют оценить собранные метрики в контексте тех норм для данной организации, которые устанавливаются SEPA.
Контролируется ли ход описанного процесса по созданию ПО в рамках данного проекта количественно (например, посредством использования количественных методов анализа)?.
А Все данные собираются и передаются SEPA в процессе выполнения оценок состояния. Эти метрики служат для установления обратной связи при планировании каждой последующей итерации.
Известны ли количественные характеристики возможностей стандартного процесса по созданию ПО в рамках данного проекта?.
А В приложении к политике организации должны быть описаны процедура оценки текущего состояния процесса и план улучшения процесса в терминах количественных показателей.
Следует ли проект политике организации в области измерения и контроля за ходом выполнения описанного процесса по созданию ПО в рамках данного проекта (например, как в рамках проекта планируется обнаруживать, определять и контролировать особые причины отклонений) ?.
А План разработки ПО должен определять метрики для измерения и контроля за процессом создания ПО. В нем также должно содержаться требование, чтобы этот процесс (и механизмы его контроля) изменялись и совершенствовались по ходу выполнения проекта.
Адекватны ли ресурсы, выделяемые на осуществление деятельности по управлению количественными показателями процесса (например, финансирование, вспомогательные программные инструменты и программа выполнения измерений для данной организации)?.
А Адекватность ресурсов, выделяемых на управление процессом, не определяется политикой. Хорошей контрольной цифрой является следующее значение: достаточное число команд приблизительно равняется корню квадратному из числа выполняемых проектов.
Используются ли измерения для определения состояния деятельности по управлению количественными показателями процесса (например, затраты на управление количественными показателями процесса и на достижение контрольных точек при управлении количественными показателями процесса)?.
Проверяет ли менеджер проекта деятельность по управлению количественными показателями проекта как на регулярной основе, так и при наступлении определенных событий?.
А Выполнение оценок состояния и основные контрольные точки предопределяют как регулярные, так и при наступлении определенных событий проверки данных по управлению количественными показателями проекта.
Управление качеством ПО, уровень 4.
Запланирована ли в рамках проекта деятельность по управлению качеством ПО?.
а Спецификации версий определяют ожидаемые значения параметров качества. Эти спецификации создаются для каждой итерации и документируются в оценках состояния (свидетельствах прогресса) и в описаниях версий (для основных контрольных точек).
Ставятся ли в проекте определенные количественно и по приоритетам цели по управлению качеством его программных продуктов (например, функциональные возможности, надежность, удобство сопровождения и эксплуатации) ?.
А Для этого существуют спецификации версий и соответствующие им демонстрации, описания версий и метрики.
Позволяет ли сравнение измерений качества программного продукта с целевым качеством программного продукта определить, достигнуты ли цели?.
А Общая концепция проекта, спецификации версий и описания версий позволяют отслеживать достижение целевого качества. Выполнение оценок состояния также регулярно дает информацию относительно достижения определенного минимального набора показателей качества.
Следует ли проект политике организации в области управления качеством ПО?.
А Политика организации действительно определяет механизмы управления качеством ПО (спецификации версий, описания версий, параметры качества, PRA и CCB/SC0).
Проходят ли члены группы по разработке ПО и других групп, имеющих отношение к ПО, необходимое для управления качеством ПО обучение (например, обучение по сбору измеряемых данных и по преимуществам количественного определения качества продукта)?.
а Вопрос не рассматривается.
После выявления причин дефектов расставляются ли наиболее распространенные причины по значимости и производится ли их систематическое устранение?.
А Вопрос не рассматривается.
Следует ли проект политике организации в области деятельности по предотвращению дефектов?.
А Вопрос не рассматривается.
Проходят ли члены группы по разработке ПО и других имеющих отношение к ПО групп необходимое для осуществления их деятельности по предотвращению дефектов обучение (например, обучение по методам предотвращения дефектов, по проведению встреч до начала выполнения задач и по анализу причин появления дефектов)?.
А Обучение зависит от конкретной организации.
Проводятся ли измерения деятельности по предотвращению дефектов (например, временных и финансовых затрат на обнаружение и исправление дефектов, а также количества предложенных, открытых и завершенных проблем)?.
А В проектах должен использоваться набор метрик, позволяющий определять эффективность исправления и состояние дефектов. Деятельность по предотвращению дефектов специально не описывается и не подвергается формализации, но ее основы четко определены посредством параметров управления и качества. PRA-рассмотрения, SCO и ССВ предоставляют различные механизмы для предотвращения дефектов на практике.
Подвергаются ли деятельность по предотвращению дефектов и ее промежуточные продукты SQA-рассмотрениям и проверкам?.
А Все оценки состояния и PRA-рассмотрения предоставляются SEPA (для SQA данной организации). Оценки состояния распространяются среди персонала проекта и заинтересованных сторон, а данные no SCO рассматриваются ССВ для подтверждения того, что весь персонал вносит свой вклад в получение данных по предотвращению дефектов.
Управление изменением технологии, уровень 5.
А На каждой новой итерации при осуществлении проекта имеется возможность внесения усовершенствований в план создания ПО. Политика организации также нуждается в периодической переоценке и усовершенствовании.
Следует ли организация принятой политике в области реализации усовершенствований процесса создания ПО?.
а Такая политика должна включаться в виде приложения в общую политику организации.
Требуется ли обучение усовершенствованиям процесса создания ПО для руководящего состава и для технических работников?.
А Обучение зависит от конкретной организации.
Используются ли измерения для определения состояния деятельности по совершенствованию процесса создания ПО (например, эффекта от реализации каждого усовершенствования процесса по сравнению с объявленными целями)?.
А От политики организации и SEPA требуются регулярные оценки R0I от деятельности по усовершенствованию в рамках данной организации.
7. Рассматривается ли деятельность по совершенствованию процесса создания ПО вышестоящим руководством на регулярной основе?.
а Генеральный менеджер организации отвечает за утверждение всех изменений в политике организации.
Е.4 ВОПРОСЫ, КОТОРЫЕ НЕ ВОШЛИ В «ВОПРОСНИК ДЛЯ ОПРЕДЕЛЕНИЯ ЗРЕЛОСТИ».
Для оценки зрелости процесса данной организации я бы задал еще несколько групп вопросов, которые на сегодняшний момент не являются ключевыми областями для СММ. В то время как предыдущие ответы непосредственно следуют «Вопроснику для определения зрелости», приводимые ниже вопросы соответствуют другим политике, механизмам и подходам к современному процессу, для которых СММ является слабой мотивацией. Эти вопросы помогут при оценке дополнительных критериев, определяющих успех схемы современного процесса.
Отчетность персонала, уровень 2.
Одной из важных задач управления созданием ПО являются четкое распределение обязанностей и механизмы отчетности. Соответственно, приводимые ниже вопросы также следовало бы задать для оценки реализации процесса в данной организации.
Автоматизирована ли «круговая» разработка?.
Можно ли сказать, что рабочие продукты тестирования создаются и сопровождаются с помощью тех же самых инструментов, методов и управления изменениями, что и основные рабочие продукты?.
Адекватно ли автоматизировано регрессионное тестирование?.
Используются ли случайные сценарии и внеурочное тестирование для обеспечения статистического тестового покрытия?.
Интегрированы ли редакторы языков программирования, среда управления конфигурацией, компилятор и отладчик?.
Разработка архитектуры, уровень 3.
Организация, в которой не уделяется систематически большое внимание архитектуре, вряд ли станет обладательницей зрелого процесса. Ответы на следующие вопросы помогут выполнить оценку с этой точки зрения.
Доступно ли инструментальное оснащение, которое обеспечивало бы объективное понимание характеристик демонстраций (в отличие от разрабатываемого заново для каждого проекта)?.
Верным признаком того, что организация достигла этого уровня зрелости, будет ее способность (1) предоставить развернутые ответы на вопросы документа с подробным объяснением специфичных для организации и проекта реализаций и (2) проиллюстрировать каждый ответ конкретными примерами из опыта в данной области. Если процедура подготовки к такой проверке процесса требует более одной или двух человеко-недель, то SE.PA является в большей степени вывеской, чем фактором, приносящим пользу в работе организации. Дополнительное обеспечение, необходимое для проверки процесса, должно являться естественным побочным продуктом процесса управления проектом.
Чтобы бизнес оставался конкурентоспособным, его рабочие процессы (как производственные, так и финансовые) необходимо постоянно совершенствовать. По этой причине существует потребность в оценке результатов таких новшеств. Как говорится, "нельзя улучшить то, что нельзя измерить". Чтобы решить поставленную задачу, бизнес должен разработать метрические показатели для измеримых составляющих бизнес-процессов и организовать сбор аналитических данных до и после нововведений. Последующий анализ показателей позволит сделать вывод о том, насколько эффективны были изменения в процессах. Но начинать необходимо с выбора самых важных показателей для ваших бизнес-процессов.
Часть 1
Организация системы оценки рабочих процессовОпределите, что именно нуждается в измерении. Другими словами, что должно дать вам очередное нововведение. Вы хотите сделать рабочий процесс более надежным, быстрым, эффективным или улучшить его каким-то иным образом? Ответ на этот вопрос внесет определенную ясность в ваш замысел. Убедитесь в том, что на выходе рабочего процесса есть определенный результат, который можно измерить тем или иным образом.
Используйте унифицированный набор терминов для своего проекта. Вам необходимо использовать общеизвестные термины, чтобы все правильно их понимали и последовательно ими пользовались. Это повысит достоверность информации, которая передается между работниками различных агрегатов или подразделений. Чтобы не происходило недопонимания, дайте четкое определение всем показателям, которые необходимо измерять.
Определите способ сбора данных. Данные необходимо собирать единообразно во всех подразделениях компании. Например, если один отдел использует случайную выборку данных, точно так же должны делать и остальные подразделения. В ином случае данные будут несопоставимыми. Также необходимо утвердить единицы измерения. Они обязательно должны быть одинаковыми, в каком бы подразделении ни производилась оценка результатов.
Стандартизируйте точность производимых вычислений. Это означает, что один отдел не должен округлять время до полного часа, а другой при этом отражать его с сотыми долями. В ином случае различный уровень детализации данных сделает некорректными общие результаты. Помните о том, что меньшие единицы измерения позволят дать более точную оценку результатов.
В дополнение к основному метрическому показателю выберите сопутствующие показатели деятельности. Оценка сопутствующих показателей позволит понять, как изменения в рабочих процессах помогают компании достичь одну из основных целей ее деятельности. Например, если основным метрическим показателем производства была выбрана скорость выпуска продукции, он может быть напрямую связан с увеличением прибыли компании или сокращением постоянных издержек. Между основным и сопутствующими метрическими показателями обязательно должны присутствовать причинно-следственные связи. Именно они позволяют доказать, почему бизнесу важно заниматься улучшением основных показателей производства.
Учтите вероятность непредвиденных результатов. Нововведения могут принести с собой не только пользу, но и побочный вред. Если основной метрический показатель должен измерять то, что следует улучшить, то дополнительно к нему необходимо использовать ряд косвенных показателей, которые должны измерять то, чему не следует меняться. Аналитику косвенных показателей нужно собирать до, во время и после внедрения соответствующего проекта. Изо всего набора косвенно связанных с проектом показателей необходимо выбрать лишь несколько самых важных, которые учитывают качество выпускаемой продукции.
Утвердите финансовые показатели. Экономия средств может и не быть основной задачей компании. Темнее менее, предприятие должно отслеживать финансовые результаты от внедрения изменений в рабочие процессы. Но не следует путать их с расчетом стоимости самого проекта изменений. В данном случае финансовые показатели должны быть средством оценки прибыльности этого проекта. Многие компании продолжают отслеживать финансовую метрику еще целый год после внедрения изменений.
Часть 3
Сбор аналитических данныхИзмеряйте время. Оценка длительности бизнес-процессов позволяет понять, сколько времени тратится на отдельные этапы производства продукции или оказания услуги. Также может производиться учет времени, которое уходит на создание добавленной стоимости продукта или которое требуется, чтобы дать ответ на запрос клиента. Кроме того, здесь могут применяться такие расчетные показатели, как процент поставок, выполненных без нарушений договорных сроков.
Измеряйте затраты. Статистика затрат должна отражать стоимость производственного процесса в целом. Также в нее должны входить операционные издержки различных уровней производственного процесса. Такой показатель, как себестоимость в расчете на единицу продукции, позволяет оценить стоимость производства единицы продукта. А экономия себестоимости может выражаться снижением этого показателя на единицу продукции. Экономия трудозатрат будет выражаться снижением рабочих часов, необходимых на производство продукта или услуги.
Оценивайте качество. Показатели оценки качества позволяют измерить уровень удовлетворенности клиентов. Информацию об удовлетворенности клиентов можно собрать посредством опросов, регистрации жалоб и прочих отзывов. Показатели оценки качества также помогают выяснить, есть ли в изменении бизнес-процессов какая-либо польза для клиентов. Здесь можно обратить внимание на частоту ошибок и потребность в переделке работ. Доля брака позволяет оценить процент производственных ошибок. Доля качественных товаров или работ позволяет понять, насколько часто в производстве отсутствуют ошибки.
