–°—В–∞–љ–і–∞—А—В—Л —Б–Є—Б—В–µ–Љ—Л –Ш–°–Ю 9000 - —Н—В–Њ –±—О—А–Њ–Ї—А–∞—В–Є—З–µ—Б–Ї–∞—П "–Љ–µ–ї—М–љ–Є—Ж–∞", —А–µ–Ј—Г–ї—М—В–∞—В –њ–Њ–њ—Л—В–Ї–Є —А–µ—И–µ–љ–Є—П –њ—А–Њ–±–ї–µ–Љ—Л –Ї–∞—З–µ—Б—В–≤–∞ –Љ–µ—В–Њ–і–∞–Љ–Є –±—О—А–Њ–Ї—А–∞—В–Є–Є –ґ–µ. (–Я. –®–Њ–ї—В–µ—Б)

”правление качеством проектов корпоративных информационных систем

ћ.√.  руглов, ѕ.ћ.  озлов


     «а последние годы на российском рынке по€вилось много компаний, предлагающих свои услуги по автоматизации различных видов де€тельности предпри€тий. —пектр их предложений довольно широк - от комплексных систем, включающих поддержку управлени€ производственно-хоз€йственной де€тельностью, бюджетное управление, конструкторскую и технологическую подготовку производства, системы электронного документооборота, до простых программных продуктов, решающих локальные задачи отдельно вз€того подразделени€ предпри€ти€. —прос на такие услуги растет, но при этом возрастают и требовани€ со стороны заказчиков по времени, затратам и качеству предлагаемых решений. " оробочна€" поставка даже простых информационных систем уже никого не устраивает, так как с внедрением любого программного обеспечени€ (ѕќ), автоматизирующего работу, измен€етс€ де€тельность подразделений предпри€ти€. ј внедрение систем класса ERP на наших предпри€ти€х вообще невозможно без существенного изменени€ системы управлени€ и организации работы заказчика.       рупный проект по созданию информационной системы (»—) предпри€ти€ всегда включает множество задач, св€занных с общим управлением проектом, разработкой ѕќ, проектированием »—, внедрением ERP-системы, кажда€ из которых сама по себе €вл€етс€ проектом с присущими ему особенност€ми. ѕод крупным понимаетс€ проект, в котором:
  • сметна€ стоимость - от 800 тыс. долл. и выше;
  • срок реализации - от года и больше;
  • число вовлеченных участников - от нескольких дес€тков до сотен человек, которые работают в трех и более организаци€х, часто территориально удаленных друг от друга;
  • развиты цепочки субподр€дных работ.
          ак правило, вести такие проекты без реально действующей системы управлени€ качеством практически невозможно. ƒаже если на начальном этапе компании, вз€вшиес€ за реализацию крупных проектов, не задумываютс€ об этом, осознание необходимости системы управлени€ качеством проекта приходит довольно быстро. ќсобенно, когда проблемы управлени€ начинают расти с каждым днем в геометрической прогрессии.
         ќбщие методические указани€ по управлению качеством проектов даны в »—ќ 10006:1996 "јдминистративное управление качеством. –уковод€щие указани€ по обеспечению качества при управлении проектом", »—ќ 10007:1995 "јдминистративное управление качеством. –уковод€щие указани€ по управлению конфигурацией". ѕо управлению качеством проектов в области информационных технологий (»“-проекты) существуют специализированные стандарты, например, стандарты COBIT1 [1] или корпоративный стандарт Microsoft MSF2 [2]. Ќо крупные проекты имеют три основные особенности.
         ѕерва€ - смена задач в ходе проекта. Ётим могут "страдать" и мелкие »“-проекты, но именно в крупных последстви€ бывают особенно т€желыми. „асто первоначальна€ постановка задачи существенно мен€етс€ в ходе проекта.  роме того, при внедрении проектных решений необходима реорганизаци€ де€тельности заказчика, при этом посто€нно должны уточн€тьс€ и корректироватьс€ функциональность разрабатываемой системы и отслеживатьс€ потребности заказчика при изменении его бизнес-процессов.  ак правило, любое неуправл€емое изменение в функциональности создаваемой »— или работах, осуществл€емых в рамках проекта, существенно сказываетс€ на качестве проектных решений и может вообще привести к краху проекта. » это необходимо учитывать при управлении проектом.
         Ќа схеме 1 показаны основные элементы крупномасштабных проектов.

    —хема 1
         ¬тора€ - параллельное ведение работ разными проектными группами. Ќапример, одновременно могут выполн€тьс€ работы по эскизному проектированию всей »—, разрабатыватьс€ ѕќ, обеспечивающее интеграцию существующих »— предпри€ти€ с разрабатываемой системой, вестись внедрение отдельных модулей ERP-системы. ¬ сочетании с первой особенностью это может вызвать лавинообразный рост трудозатрат по проекту.
         “ем самым параллельность и многоплановость работ, выполн€емых в крупном проекте по разработке и внедрению »—, многократно увеличивает веро€тность возникновени€ рисков неудачного завершени€ проекта. ќдна из важных задач управлени€ качеством крупного проекта - добитьс€, чтобы к моменту его завершени€ "срослись" все компоненты системы и были выполнены требовани€ заказчика по функциональности, срокам и стоимости системы.
         “реть€ - очень большие риски как дл€ заказчика, так и дл€ исполнител€ проекта. ¬ данной работе риск - это произведение величины ущерба (изменение сроков проекта, трудозатрат и т. д.) на веро€тность его возникновени€. –иски заказчика св€заны с неполным достижением целей проекта и не эффективно израсходованными средствами, а риски исполнител€ - с возможностью резкого превышени€ фактической себестоимости работ по сравнению с плановой. ѕричинами превышени€ €вл€ютс€ как раз перва€ и втора€ особенности. Ќеобходимость ведени€ параллельных и подчас принципиально отличающихс€ по своему характеру работ приводит к тому, что многократно возрастает уровень риска проекта.
         ѕон€тно, что реакци€ заказчика на 20%-ное изменение трудозатрат исполнител€ в проекте стоимостью 20 тыс. долл. и в крупном проекте будет разной. ѕри этом современный заказчик не очень-то позвол€ет исполнителю страховать риски за счет большого "зазора" между ценой контракта и себестоимостью работ.
         ћетоды управлени€ проектами и проектными рисками дл€ малых и средних проектов достаточно проработаны и позвол€ют эффективно снижать уровень рисков и трудозатраты по проекту. ƒл€ ведени€ крупных проектов "стандартного" набора методов оказываетс€ недостаточно (табл. 1).

    “аблица 1

    ћасштаб проекта „исло работ „исло подпроектов —в€зность работ ћетоды управлени€
    ћалый 10-50 Ќет Ќизка€ PMI3, FMEA, MSF, личный опыт руководител€
    —редний 50-100 ≈диницы Ќизка€, средн€€ —тандартные методики (ASAP4, PJM5, PMI), SPICE6, COBIT
    Kрупный 100-1000 ќт нескольких дес€тков до нескольких сотен ¬ысока€ ѕроработаны слабо

    3 PMI (Project Management Institute) - ћетодологи€ управлени€ проектами института управлени€ проектами, Pennsylvania USA.
    4 ASAP (Acceler-ated SAP) - методологи€ внедрени€ ERP-системы SAP R/3 компании SAP.
    5 PJM (Project Management) - ћетодологи€ внедрени€ ERP-системы Oracle Appications корпорации Oracle.
    6 SPICE (Software Process Improvement Capabilities and dEtermination) - ќценка и улучшение процессов разработки ѕќ.

         ¬ св€зи с этим возникает необходимость в разработке специфичной модели управлени€ качеством проекта именно дл€ крупных проектов »—.      ¬ рамках предлагаемой модели проект рассматриваетс€ как множество взаимосв€занных процессов, которые сгруппированы по фазам (этапам осуществлени€ проекта, на которых достигаютс€ какие-либо промежуточные результаты). “ака€ группировка позвол€ет отслеживать достижени€ целей и подцелей проекта и оценивать возможный риск его выхода за установленные ограничени€.  роме того, процессы проекта группируютс€ по категори€м на процессы, св€занные:
  • с управлением проектом;
  • с продуктом проекта.
         ѕроцессы управлени€ проектом группируютс€ по их сродству, например, те из них, которые св€заны со сроками (временем), включаютс€ в одну группу. ѕрактически во всех проектах в той или иной степени бывают представлены группы процессов установлени€ целей проекта, управлени€ взаимосв€з€ми процессов в проекте, а также процессы, св€занные с проектным заданием, сроками, затратами, ресурсами, кадрами, информационными потоками, менеджментом рисков и материально-техническим снабжением.
         —труктура всех процессов проекта св€зана с конфигурацией »— таким образом, чтобы в любой момент осуществлени€ проекта была возможность реализовать требовани€, предъ€вл€емые к »— на различных стади€х ее жизненного цикла. ќна определ€ет отношени€ между видами де€тельности, непосредственно касающимис€ процессов проекта и характеристик создаваемой »—, в их числе функции управлени€ конфигурацией, проектирование »—, материально-техническое обеспечение, заключение контрактов, управление информацией и т. п.
         »— на каждом этапе ее построени€ обладает определенной базовой дл€ данного этапа конфигурацией. —оответственно и процессы проекта должны быть выстроены таким образом, чтобы в результате их осуществлени€ была достигнута именно эта конфигураци€.
         ”правление конфигурацией »— и процессами проекта позвол€ет координировать управление перечисленными видами де€тельности, исход€ из тех изменений, которые посто€нно возникают в ходе реализации проекта.
         ѕри разработке и внедрении »— существует много причин, привод€щих к возникновению рисков: ошибки в выборе стратегии проекта, нечетко поставленные цели и задачи, изменение внешних и внутренних требований, низка€ квалификаци€ персонала и т. д.
         ќдна из важных особенностей предлагаемой модели - управление рисками такого проекта, которое во многом строитс€ на управлении конфигурацией »— и процессами проекта (табл. 2).  роме того, умение управл€ть разработкой и внедрением »— требует от компаний создани€ своей собственной корпоративной культуры, т. е. участники проекта должны уметь оценивать риски и выгоду в рамках каждого проекта, принимать на основе этих оценок быстрые и адекватные проектные решени€, легко и без серьезных потерь реагировать на изменени€ требований заказчиков и условий рынка.

    “аблица 2

    ¬иды рисков/варианты менеджмента рисков —нижение видов риска ƒопущение риска (дл€ крупных проектов, как правило, не срабатывает) –аспределение риска —нижение веро€тности возникновени€ риска
    –иски, св€занные с масштабом проекта ƒетальный анализ каждого этапа работ, взаимодействи€ участников, организации работ ”величение трудоемкости работ и стоимости проекта –азделение проекта на несколько подпроектов, выделение пилотного проекта по подсистемам (ограниченного масштаба) ƒетально проработанна€ программа качества, отработанное управление конфигурацией проекта, специальные процедуры взаимодействи€ участников
    –иски, св€занные с недостаточным опытом в сфере »“ ѕроведение обучени€ пользователей, включа€ руководство, соблюдение технологий работы ”величение трудоемкости работ и стоимости проекта —огласование с заказчиком большинства проектных документов, согласование всех изменений в функциональности системы –азработка и утверждение концепции проекта на возможно более ранней его стадии
    “ехнические риски проекта —трогий отбор проектной команды по квалификационным критери€м. ќбучение участников проекта технологии проектных работ, инструментальным средствам ”величение трудоемкости работ и стоимости проекта ƒокументально зафиксированна€ персональна€ ответственность участников проекта, документальное фиксирование всех изменений в процессе проекта »спользование стандартов предпри€ти€ на проектные работы, разработка стандартов проекта
    ќрганизационные риски проекта ќбучение участников проекта (курс "управление проектом"), тренинги команды, как можно более полна€ формализаци€ де€тельности ”величение трудоемкости работ и стоимости проекта ¬ключение представителей заказчика в рабочие группы ¬ключение в команду администратора проекта, детальное распределение ролей в проекте
    ќперационные риски проекта ћногократное тестирование созданных продуктов, тщательна€ экспертиза документов ”величение трудоемкости работ и стоимости проекта јкт сдачи заказчику любого документа. ‘иксирование отсутстви€ претензий заказчика по каждому этапу работы —трогое выполнение процедур программы качества

         ќчевидно, что чем сложнее проект, тем сильнее про€вл€етс€ взаимосв€зь проектных рисков и, следовательно, тем более формализованным должно быть управление проектами дл€ адекватного снижени€ этих рисков. ¬ крупных проектах работы обладают высокой св€зностью, что приводит к тому, что любые изменени€ в одном процессе так или иначе вли€ют на другие процессы проекта [3].
         ¬ основе модели управлени€ качеством крупного проекта должна находитьс€ система управлени€ рисками проекта.
         ѕрактически любой процесс проекта имеет свой собственный (специфичный) набор рисков и некоторый общий набор рисков дл€ всех процессов проекта. ¬ соответствии со стандартом »—ќ 10006:1996 управление рисками включает следующие виды де€тельности:
  • вы€вление - определение рисков в проекте;
  • оценка - оценивание веро€тности по€влени€ рисковых событий и их воздействи€ на проект;
  • развитие реакции - разработка планов реагировани€ на риски;
  • контроль за рисками - реализаци€ и обновление рисковых планов.
         ƒл€ вы€влени€ рисков первоначально необходимо выбрать объекты, которые будут анализироватьс€.   ним относ€тс€ процессы и продукты проекта.  ак правило, в сферу анализа рисков невозможно включить все процессы и продукты проекта, так как это может потребовать неприемлемых затрат времени и сил, поэтому приходитс€ останавливатьс€ на некоторых наиболее важных и критичных процессах и продуктах. ѕоможет в выборе таких процессов анализ конфигурации. ¬ стандартах »—ќ/ћЁ  12207:1995 "»нформационные технологии. ѕроцессы жизненного цикла программного обеспечени€" и »—ќ 10007:1995 представлены процедуры и задачи, которые должны выполн€тьс€ при управлении конфигурацией.  онфигураци€ проекта обычно основываетс€ на спецификаци€х »— на определенном этапе работ и процессах, выполнение которых приведет к созданию этой системы. “ак же можно определить взаимосв€зи процессов и соответственно наметить возможные "переходные" риски.
         ѕри вы€влении и анализе рисков существенную помощь могут оказать формализованные методы. Ќапример, в стандарте SPICE описаны 35 основных процессов, используемых при создании »— и методы их оценки. «десь же привод€тс€ п€ть категорий процессов (взаимодействи€ поставщика и потребител€, проектировани€, обеспечени€, управлени€ и организационные процессы) и набор соответствующих базовых методов. ѕри сравнении действующих процессов проекта с приведенными референтными модел€ми можно вы€вить веро€тные риски каждого из процессов [4]. ѕроцессы, уровень адекватности которых оказалс€ неудовлетворительным, имеют высокую веро€тность возник     ѕри вы€влении и анализе рисков существенную помощь могут оказать формализованные методы. Ќапример, в стандарте SPICE описаны 35 основных процессов, используемых при создании »— и методы их оценки. «десь же привод€тс€ п€ть категорий процессов (взаимодействи€ поставщика и потребител€, проектировани€, обеспечени€, управлени€ и организационные процессы) и набор соответствующих базовых методов. ѕри сравнении действующих процессов проекта с приведенными референтными модел€ми можно вы€вить веро€тные риски каждого из процессов [4]. ѕроцессы, уровень адекватности которых оказалс€ неудовлетворительным, имеют высокую веро€тность возникновени€ риска (схема 2). Ќаличие в стандарте также перечн€ входных и выходных данных, необходимых дл€ исследовани€ того или иного метода, позвол€ет при оценке процесса определить вид риска.  онечно, ни один стандарт не в состо€нии описать полный набор возможных методов и данных, которые могут примен€тьс€ в том или ином проекте, но отсутствие базовых методов в управлении проектом почти наверн€ка приведет к возникновению риска.

    —хема 2
         ”правление риском - сложный итерационный процесс. ¬се его этапы тесно св€заны между собой, поэтому при выполнении каждого этапа может возникнуть необходимость повторени€ предыдущего. Ќапример, при оценке риска может оказатьс€, что выбранных процессов дл€ проведени€ анализа недостаточно, так как риск, имеющий большую веро€тность возникновени€, передаетс€ в процесс, первоначально не включенный в анализ.
         ¬ажным этапом работ по управлению риском проекта €вл€етс€ разработка планов реагировани€ на риск.  ак правило, дл€ разработки таких планов недостаточно идентифицировать и оценить риски, необходимо еще и провести анализ причин их возникновени€. ќдним из простых и достаточно эффективных методов такого анализа может служить метод FME(—)A (Failure Mode, Effects and (Criticality) Analysis) - метод анализа видов, последствий и (критичности) отказов (дефектов). Ќа этом этапе работ определ€етс€ стратеги€ внесени€ изменений в проект, так как конфигураци€ проекта находитс€ в пр€мой зависимости от веро€тных рисков процессов. ѕри необходимости планы реагировани€ на риск должны строитьс€ на основе данных предыдущих аналогичных проектов, так как это уменьшит веро€тность внесени€ новых рисков. —оставл€€ планы реагировани€ на риск, целесообразно учитывать возможность с помощью одного меропри€ти€ предотвратить несколько рисков. “ака€ возможность по€вл€етс€, например, при наличии "переходных" рисков.
          огда намеченные меропри€ти€ по предотвращению или снижению рисков выполнены, надо убедитьс€, что они оказали требуемое воздействие. ƒл€ этого вы€вленные риски проекта необходимо контролировать с помощью итеративных процессов идентификации и оценки рисков. ≈сли после осуществлени€ запланированных меропри€тий риски наход€тс€ на приемлемом уровне, значит проведенный анализ рисков и меропри€ти€ по их снижению оказались эффективными. ¬ противном случае потребуетс€ проанализировать допущенные ошибки и повторить все этапы управлени€ риском проекта.      ѕроект по автоматизации де€тельности предпри€ти€ - сложна€ система, подверженна€ различному вли€нию внутренних и внешних рисков. Ёти факторы могут быть заложены в организации самого проекта или стратегии достижени€ целей проекта, либо выступать результатом де€тельности как участников проекта, так и внешних по отношению к проекту сторон. –иски любого проекта всегда имеют объективную и субъективную основы. ¬ качестве объективной, как правило, выступают услови€ внешней среды, на которые де€тельность по управлению проектом и качеством проекта не в состо€нии оказывать более или менее существенного воздействи€ (например, законодательство, регулирующее предпринимательскую де€тельность, налогова€ система, взаимоотношени€ с партнерами, экономическа€ обстановка в стране, стихийные бедстви€ и т. д.). ƒействи€ по снижению рисков этих видов ведутс€ на уровне всей компании, а не на уровне отдельно вз€того проекта.
         —убъективную основу рисков составл€ют принимаемые управленческие решени€. ѕоэтому дл€ эффективного управлени€ проектом очень важно знать степень вли€ни€ таких субъективных факторов на достижение целей проекта.
         ¬нутренние риски проекта определ€ютс€ масштабом проекта (риски, вызванные несогласованностью действий многочисленных исполнителей, представителей заказчика и т. д.); недостаточным опытом и заказчика, и исполнител€; неизвестными на момент начала проекта ошибками в используемом инструментальном и прикладном ѕќ (технические риски); организацией де€тельности участников проекта, примен€емыми управленческими технологи€ми (организационные риски); отличием фактически протекающих бизнес-процессов проекта от их предполагаемого вида (операционные риски).
         Ќа все группы внутренних рисков проекта существенно вли€ют:
  • организаци€ проекта;
  • конфигураци€ проектируемой системы;
  • ресурсы проекта;
  • структура процессов проекта.
         —ледует заметить, что эти четыре составл€ющих включают дес€тки конкретных, действующих в каждом проекте специфичных и присущих только этому проекту факторов.
         ќрганизаци€ проекта включает многие аспекты, например, определение состава и ролей его участников, установление пор€дка их взаимодействи€, распределение ответственности и полномочий, выработку методов ведени€ проектов.  ак правило, больша€ часть этих работ выполн€етс€ на начальных стади€х проекта.  роме того, число и состав участников проекта могут часто мен€тьс€ от фазы к фазе его жизненного цикла. Ёто приводит к тому, что методы и средства управлени€ проектом, эффективные на одной фазе, могут оказатьс€ неприменимыми на последующих.
          онфигураци€ проектируемой системы существенно вли€ет на состав работ и участников проекта, структуру рисков и практически всегда подвергаетс€ изменени€м. Ёто обусловлено уникальностью проекта и создаваемой »—.
         ƒл€ успешного осуществлени€ проекта необходимы люди, материальные, финансовые и временные ресурсы, которые удовлетвор€ли бы определенным требовани€м. ѕричем на каждом этапе проекта к ресурсам предъ€вл€ютс€ свои требовани€, которые определ€ют входы многих процессов. Ётим обусловлено значительное вли€ние качества ресурсов на характер рисков каждого конкретного процесса.
         —труктура процессов проекта во многом задаетс€ цел€ми и подцел€ми проекта, т. е. теми промежуточными и конечными результатами, которые должны быть достигнуты в ходе реализации проекта. —труктура рисков проекта св€зана со структурой его процессов, так как практически каждый процесс обладает присущими только ему рисками. ƒл€ эффективного анализа эти риски целесообразно структурировать по родственным причинам возникновени€.  ак правило, риски процессов проекта могут быть структурированы по классам с выделенными подклассами эквивалентности, типам процессов, св€з€м между ними и параметрами (ограничени€ми) каждого процесса.      јнализ рисков крупных проектов позвол€ет выделить следующие особенности:
  • риски "наследуютс€", т. е. риск на определенной стадии проекта может зависеть от факторов, не только действующих на этой стадии, но и от действовавших на предыдущих;
  • риски измен€ютс€ в зависимости от того, произошло или не произошло рисковое событие на предыдущей стадии проекта.
         Ёти особенности обычно не учитывают при анализе рисков "некрупных" проектов, риски считают независимыми и неизменными [4], при этом ошибка лежит в допустимых пределах. ј вот в случае крупных проектов пренебрежение приведенными особенност€ми может привести к существенным ошибкам.
         ƒл€ эффективной оценки рисков проекта с учетом этих особенностей их целесообразно структурировать по уровн€м. ¬ерхний уровень - риски, присущие группе бизнес-процессов, охватывающих весь проект, а также внешние риски.  ак правило, управлением и анализом этого уровн€ рисков занимаетс€ руководство проекта и организации. Ќижний уровень - риски, существующие в рамках каждого бизнес-процесса проекта. ”правлением рисками этого уровн€ занимаетс€ персонал проекта.
         ¬ерхний уровень рисков св€зан со стратегическими цел€ми проекта, такими как:
         организаци€ и ведение процессов проекта;
         изменени€ затрат и сроков проекта;
         изменение требований к продукту проекта.
         Ќа нижнем уровне в основном присутствуют специфичные риски каждого конкретного процесса проекта. Ќапример, риски, св€занные с материально-техническим снабжением, документированием, разработкой и т. д.
         “ак как все процессы проекта взаимосв€заны, и выполнение их обычно идет параллельно, то возникает ситуаци€ "переходных" рисков двух направлений. √оризонтальные - риски одного процесса переход€т в риски другого процесса, и вертикальные - риски совокупности процессов переход€т в риски верхнего уровн€ (например, из-за ошибок при вы€влении требований к системе необходимо измен€ть функционал системы, а это ведет к риску увеличени€ затрат и сроков работ и может привести к изменени€м целей проекта). »спользу€ сетевые графики и диаграммы √анта, традиционно примен€емые дл€ администрировани€ и управлени€ проектом, вы€вить наследование и передачу рисков оказываетс€ затруднительно (схема 3).

    —хема 3
         ѕри передаче риска из процесса в процесс или с одного этапа работ на следующий действует правило 10-кратного увеличени€ последствий возникновени€ рискового событи€. Ќапример, если риск одного процесса не был вы€влен и повли€л на выполнение другого, св€занного с первым процессом, то усили€ на устранение последствий возникшего рискового событи€ потребуют в 10 раз больше затрат (временных, материальных, людских), чем если бы этот риск был устранен в первом процессе [5]. “аким образом, важно выбрать такую методику оценки риска, котора€ бы позвол€ла учитывать возможность передачи риска из процесса в процесс. Ќа схеме 4 представлен фрагмент структуры процессов проекта (в соответствии с графиком схемы 3) и указан момент возникновени€ рисковых событий P1 и P2, которые передаютс€ в последующие процессы. „исла в узлах графа обозначают номер работы по списку, а числа в скобках - число веро€тных рисков, присущих каждой работе.

    —хема 4
          ак видно из схемы 4, при наследовании рисков происходит их эскалаци€. ѕричем риски, изначально определенные дл€ конкретных процессов, измен€ютс€ по своему составу. ¬ последующих процессах возникают совершенно новые риски, которые привод€т к изменени€м как состава работ, так и конфигурации проектируемой системы. ѕо€вл€ютс€ дополнительные работы дл€ устранени€ возникших несоответствий, или приходитс€ сокращать сроки отдельных работ, зачастую с потерей качества и функциональности системы. ≈сли не учитывать эти обсто€тельства в крупных проектах, где цепочки взаимосв€зи работ очень сложные и большие, то трудоемкость работ по созданию корпоративной системы в той конфигурации, котора€ была изначально определена дл€ данного этапа проекта, может стать просто катастрофической.
         ¬ыводы. Ёффективное управление проектами невозможно без управлени€ рисками, в том числе "переходными", т. е. способными передаватьс€ от процесса к процессу. »х вы€вление должно строитьс€ на основе структуры (конфигурации) процессов проекта и анализе возможных рисков проекта. Ёто позвол€ет реализовать проблемно-ориентированный и гибкий подход к управлению качеством проекта, начина€ с первичной оценки существующих процессов, описанием вариантов реализации, оценки выбранных решений, определением требований к ресурсам проекта в каждый момент его реализации и заканчива€ внедрением эффективных методов управлени€ проектом на базе анализа веро€тностных рисков.




    —ѕ»—ќ  »—ѕќЋ№«ќ¬јЌЌќ… Ћ»“≈–ј“”–џ
    1. COBIT - Released by the COBIT Steering Committee and the Information Systems Audit and Control Foundation. 2nd edition, 1998.
    2. Microsoft MSF - Microsoft Solutions Framework, 1999.
    3.  ал€нов √.Ќ. “еори€ и практика реорганизации бизнес-процессов. - ћ.: —интег, 2000.
    4. ISO/IEC 15504-8:1998. Information technology. Software process assessment.
    5.  руглов ћ.√., —ергеев —. ., “акташов ¬.ј. ћенеджмент систем качества. - ћ.: »ѕ  »здательство стандартов, 1997.



    1 COBIT (Control Objectives for Information and Related Technology) -  онтроль целей дл€ информационных и св€занными с ними технологи€ми.
    2 MSF (Microsoft Solutions Framework) - ћетодика управлени€ проектами разработки информационных систем Microsoft.

    ѕодготовлено по материалам –»ј "—тандарты и  ачество"





    “акже на сайте:
    ”топии, мифы и иллюзии менеджмента
    ”довлетворенность потребителей и ло€льность

    ѕодготовлено при поддержке:
  • ќ проекте

    quality.eup.ru - один из самых старых в рунете ресурсов, посв€щенных менеджменту качества во всем его разнообразии.

    Ќам более 7 лет, и все это врем€ ресурс пополн€етс€ новыми и новыми материалами, почти ежедневно. ≈сли вы ищете информацию о менеджменте вообще и управлении качеством в частности, скорее всего, вы найдете эту информацию здесь.

     роме отличной и действительно большой подборки статей, действует живой форум по менеджменту качества.

    ƒобавить в "»збранное"

    –екомендуем

    Ќаш новый проект:
    ¬се о качестве менеджмента
    »збранные книги

    –еклама на сайте





     ак сюда попасть?