Диссертация (1138653), страница 4
Текст из файла (страница 4)
Такимобразом, при управлении содержанием в организационном ИТ-проекте следуетвыбирать организационные и технические решения, оказывающие положительноевоздействие именно на эти параметры.Содержание организационного ИТ-проекта включает технологическую(разработкатехнологическогорешения)иорганизационную(выполнениеорганизационного изменения на базе разработанного решения) составляющие.Количественноценность,создаваемаяорганизационнымИТ-проектом,определяется бизнес-результатами, получаемые при внедрении организационнотехнического решения.Техническидостижениетребуемойэффективностидеятельностиорганизации обеспечивается изменениями в операционных или управленческихпроцессахкомпании[Radhakrishnan,Zu,Grover,2008]посредствомпредоставления более быстрого или более простого доступа к информации,повышения качества информации для стратегического планирования, повышенияточности информации, предоставления информации в удобных форматах [Gregorand others., 2006; Olugbode, Richards, Biss, 2007].
Изменения в операционныхпроцессах затрагивают такие параметры деятельности компании как скорость илистоимость выполнения ее бизнес-процессов в результате их реинжиниринга[Ramirez, Melville, Lawler, 2010], а изменения в управленческих процессах влияютна своевременность и обоснованность принятия управленческих решений. Приэтомсвязьэффективностиорганизационногоизменениясосвойствамивнедряемого технологического решения является неочевидной [Lee, 2001].Применениепроектногоподходаобеспечиваетнаиболееэффективное18выполнение изменений, что позволяет компании адаптироваться к изменяющейсявнешней среде [Юрьева, 2017].Организационныеизмененияпрактическивсегдасопровождаютвыполнение ИТ-проектов.
Действительно, в случае проектов автоматизациибизнес-процессов организационные изменения неизбежны вследствие самогоназначения этих проектов. Что касается проектов продуктовой разработки(создание бесконечно тиражируемых продуктов для последующей продажипотребителю), то они могут предполагать, а могут и не предполагатьорганизационныхвыполненииизменений.продуктовойКомпании,разработкикоторыеИТ-решений,специализируютсякакправило,наимеютотлаженные и воспроизводимые процессы управления жизненным цикломпродукта, включая разработку концепции, сбор требований, конструированиерешения и вывод продукта на рынок. В этом случае разработка программногообеспечения является для них рутиной. Организационные изменения в такихкомпаниях существуют, но они связаны с развитием процессов управленияпроектами разработки программного обеспечения [Kettunen, Laanti, 2008;Mathiassen,Ngwenyama,Aaen,2005].Этиизменениявполнемогутрассматриваться отдельно от любого проекта разработки, так как в пределахжизненногоциклапроектасистемауправленияостаетсянеизмененной(квазистационарная система [Lewin, 1947]).
В отличие от этих организаций,компании, не специализирующиеся на разработке программного обеспечения,хотя и могут выполнять или являться заказчиками проектов продуктовойразработки (для того, чтобы создать дополнительную ценность для потребителейпутемразработкикомплексныхпродуктов,включающихаппаратнуюипрограммную части), однако не в состоянии выполнять их в рамках своихустоявшихся процессов управления жизненным циклом продукции. Как правило,управление жизненным циклом программных продуктов (разработка, вывод нарынок, продажи) требует совершенно иных компетенций, а также существеннойпереработки бизнес-процессов организации.
Разработка подобных продуктов,кроме того, может предприниматься для изменения бизнес-модели компании, что19само по себе влечет существенные изменения в бизнес-процессах [Tallon,Pinsonneault, 2011].Существенное различие в ключевых компетенциях заказчика и подрядчикав организационных ИТ-проектах приводит к невозможности согласоватьтребования на начальных этапах проекта и к разрыву в понимании образапродукта, а в случае недостаточной или неэффективной коммуникации междузаказчиком и подрядчиком в процессе реализации проекта – к росту этого разрывав течение времени [Вигерс, Битти, 2014; Дварака, 2015].
Эти проблемыобусловливают возникновение явления, называемого «расползанием требований»(scope creep), что в свою очередь приводит к невыполнению целей проекта. Приэтом изменения в требованиях, внесенные при приемочных испытаниях ивнедрении, имеют наибольшую стоимость реализации, поскольку во многихслучаях затрагивают архитектуру программного решения [Макконнелл, 2010].Названные проблемы носят системный характер и не позволяют решить проблемурасползания требований простым увеличением трудозатрат на планированиесодержания проекта [Eisenhardt, Tabrizi, 1995]. Еще более проблема усугубляетсяпри «отсутствии эффективных коммуникаций между бизнесом и IT», чтонекоторые исследователи указывают в качестве одной из важных особенностейИТ-проектов в России [Миславская, 2010].Этот тезис подтверждают также выводы обзора публикаций на темуорганизационныхизмененийиуправленияпроектами[Hornstein,2015].Хорнстейн указывает на то, что эти области знаний имеют совершенно различнуютерминологию, а также методологию, что затрудняет их интеграцию.
Вместе стем, тот факт, что осуществляемые организационные изменения оказываютнепосредственный эффект на успех управления проектами, заставляет искатьпути для преодоления этих трудностей. Статья является обзорной и не даетконкретныхрекомендацийотносительнотого,какинтеграциядолжнаосуществляться. Ценность ее состоит в том, что в ней на основе анализа большогочисла публикаций сформулирована потребность в развитии методологииуправления организационными ИТ-проектами.20Сроки реализации проекта при расползании требований могут еще большезатягиваться, так как четкое видение продукта (в этом случае отсутствует)является одним из ключевых факторов, влияющих на продуктивность командыразработки [Черникова, 2014; Lu and others, 2011].Расползание требований оказывает существенное влияние не только насроки и стоимость проекта, но и на его качество, так как задействуются такиемеханизмы, как снижение мотивации при длительной разработке, а такжеувеличение числа дефектов, вносимых программистами, работающими подпостоянным давлением сжатых сроков [Илишкин, Яковлева, 2016; Thakurta,2013].К целям организационных ИТ-проектов также должны быть предъявленыособые требования, так как в случае если цели проекта сводятся к разработкетехническогорешения,соответствующеготребованиям,тоизвниманияускользают весьма существенные аспекты, связанные с использованием продуктапроекта, что в свою очередь затрудняет разработку сценариев использования ивпоследствии приводит к расползанию требований (scope creep) [Вигерс, Битти,2014], что и является основной причиной недостижения целей в ИТ-проектах[Jones, 1996].
Цели должны пониматься расширенно и формулироваться исходя изпараметров создаваемой в проекте ценности для бизнеса, что включает в себяметрики изменяемых процессов или предоставляемых организацией услуг. Этоможет включать параметры времени выполнения бизнес-процессов, их стоимостиили качества оказания услуг [Гиматов, 2003; Гордеев, Борисов, Коршак, 2015].Сформулированные подобным образом цели являются среднесрочными, и ихреализация достаточно приближена к срокам поставки результатов проекта длятого, чтобы эффективно организовать обратную связь на основе мониторинга ихреализации.
Успех проекта в общем определяется соблюдением сроков истоимости при реализации запланированного содержания вместе с достижениембизнес-целей в описанном выше формате [Badewi, Shehab, 2016]. При этомполномочия руководителя проекта должны быть расширены для того, чтобы он21мог нести ответственность за реализацию этих параметров [Breese and others,2015; Terlizzi, Meirelles, Moraes de, 2016].Говоря о целях ИТ-проектов, следует упомянуть о различных способах ихформулирования. При этом, поскольку различные группы заинтересованныхсторон могут воспринимать успешность проектов различно, то и цели могутформулироваться на разном уровне [Дульзон, 2014]. Так, успешность проектаможет определяться достижением целей в смысле• Качества продукта, сроков и стоимости проекта;• Нефинансовыхвыгодорганизации:ростапродуктивностиилиэффективности бизнес-процессов, а также различных компетенций;• Финансовых выгод организации: роста оборота, прибыли;• Маркетинговых целей: достижение доли рынка, лидерство, узнаваемостьбренда и др.
[Дубовицкая, 2016; Davis, 2016].Данные цели различаются как уровнем в иерархии целей, так и горизонтомпланирования. Наиболее распространенными практиками являются постановкацелей проекта в техническом формате (реализация продукта в соответствии стехническим заданием в условиях ограничений по времени и затратам) или вфинансовом либо маркетинговом формате (увеличение продаж, прибыли, долирынка и т.п.) [Ермакова, 2014].Проблема постановки целей проектов организационных изменений связанас проблемой экономической эффективности проектов автоматизации, частнымслучаемкоторойявляетсяэкономическаяэффективностьавтоматизациитехнологических процессов [Корсаков, 1978; Шаумян, 1973]. Однако этапроблема шире, так как ценность включает в себя не только прямую выгоду отсокращения затрат на выполнение автоматизируемых процессов, но и выгоды,связанные с соответствием услуг, оказываемых компанией, требованиям рынка.Важно отметить, что показатели экономической эффективности проектов, такиекак рентабельность инвестиций, срок окупаемости или чистый дисконтированныйдоход не могут служить метриками ценности в ИТ-проектах, так как получениеэкономическихрезультатоввследствиеоптимизациибизнес-процессов22организации или повышения качества оказываемых организацией услуг выходитза границы собственно проекта, а значит, вклад проекта в их реализациюопосредованный, и руководитель проекта не имеет управленческих рычагов длягарантированного получения запланированных экономических результатов.Следует заметить, однако, что это утверждение не отрицает полезностииспользования названных выше показателей экономической эффективности.
Приэтом их следует применять в соответствии с их предназначением, то есть дляанализа инвестиционной привлекательности проекта. Метрики ценности, в своюочередь, должны применяться для мониторинга и оперативного управленияпроектом.В настоящее время не существует общепринятого определения ИТ-проекта.Вместо этого объект управления определяется через классификацию ИТ-проектовпо назначению[Беркун, 2007]. Традиционно, когда говорят об ИТ-проектах,подразумевают проекты разработки программного обеспечения, либо проектывнедрения программного обеспечения для автоматизации тех или иных процессовв организации.
При этом следует отметить, что и проекты внедренияпрограммных систем в организациях нередко сопровождаются существеннойдоработкой внедряемого программного обеспечения под нужды заказчика.Внедрение новой информационной системы всегда предполагает изменениебизнес-процессов организации, зачастую существенное. Внедрение полнойисходной версии программной системы при этом может предполагать весьмазначительное изменение бизнес-процессов организации-заказчика, в котороморганизация может быть не заинтересована. Или, напротив, «коробочная» версияможет не реализовывать уникальных бизнес-процессов организации, благодарякоторым компания получает конкурентное преимущество на рынке.