Причины успехов и неудач внедрений

Управление изменениями и концепция внедрения

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

Change agent (внедрение)

Организационные процедуры, нацеленные на освоение, управление и ис­пользование инновации в повседневной практике.

User-designer (агент изменений)

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

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

Одной из известных моделей процесса внедрения является модель организа­ционных изменений Кольба/Фромена (Kolb/Frohman). Здесь процесс измене­ний разбит на семь этапов, а также представлен на основе взаимосвязей между консультантом и его клиентом. (Консультант выступает в роли посредника меж­ду разработчиком информационной системы, заказчиком и пользователями.) Успешность изменений зависит от деятельности консультанта и клиента на каж­дом этапе внедрения. Другие модели основываются на связях между разработчи­ками проекта, клиентами и сотрудниками, принимающими решение, которые несут ответственность за достижение баланса между производительностью и практич­ностью системы (Swanson, 1988). Современные работы по внедрению новых си­стем выявили необходимость более гибкого подхода и импровизации со стороны участников процесса, которые больше не ограничены жесткими рамками инст­рукций (Markus, Benjamin, 1997; Orlikowski, Hofman, 1997).

Результаты внедрения во многом определяются следующими факторами:

• роль пользователей в процессе внедрения;

• степень поддержки руководством работ по осуществлению внедрения;

• уровень сложности и рискованности всего проекта;

• качество управления внедрением.

Основные поведенческие и организационные аспекты отображены на рис. 11.5. Участие пользователей и их влияние на процесс внедрения

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

тический опыт работы с системой позволяет им предоставлять полезные реко­мендации для ее модернизации и улучшения (De, Ferrat, 1998).

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

(Markus, Keil, 1994).

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

User-designer/Communications gap (взаимное непонимание между поль­зователями и проектировщиками /коммуникативная неудача)

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

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

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

Если информационный проект опирается на поддержку руководства и менедже­ров компании, то он будет более позитивно восприниматься как пользователями, так и техническим персоналом. Обе группы сотрудников будут уверены в том, что их участие в проекте привлекает пристальное внимание начальников и обла­дает высокой значимостью для всей организации. Они получат награду в какой-либо форме за то, что затратили свое личное время и силы (Doll, 19851; Ein-Dor, and Segev, 1978).

Однако поддержка руководства иногда вызывает обратный эффект. Руково­дители могут уделять проекту слишком много внимания (в ущерб другой работе) и вкладывать в него слишком много средств, что приведет к нерентабельности новой системы (Newman, and Sabherwal, 1996). Уровень сложности и риск

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

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

Размер проекта. Чем крупнее проект, оцениваемый с точки зрения финансо­вых затрат, количества занятых сотрудников, времени, необходимого на его вы­полнение, и количества организационных объектов, подверженных его влиянию, тем выше риск. Следовательно, проект, на который необходимо потратить $8 млн и два года работы 120 сотрудников из 5 отделов, будет более рискованным, чем проект, который могут выполнить два человека за два месяца, потратив на него $30 тыс. Другим фактором риска является опыт организации в реализации про­ектов такого масштаба. Если компания привыкла внедрять крупные и дорогосто­ящие системы, то степень риска при выполнении восьмимиллионного проекта будет не столь уж высокой. Риск будет даже ниже, чем в случае фирмы, которая решится на внедрение системы стоимостью в $200 тыс., когда до этого она огра­ничивалась суммами затрат в $50 тыс. Тем не менее крупномасштабные проекты на 50-75% опаснее, чем проекты «малого и среднего калибра», поскольку они очень сложны и не всегда поддаются контролю. Поведенческие характеристики системы (характер владельца системы и его влияние на бизнес-процессы) услож­няют крупномасштабный проект не меньше, чем такие технические характери­стики, как количество строк программного кода, время выполнения проекта и его бюджет (The Concours Group, 2000; Laudon, 1989; U.S. General Services Admini­stration, 1988).

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

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

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

Управление процессом внедрения

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

			Таблица 11.4
			Степени риска проекта
Структурирован-	Технический	Размер проекта	Степень риска
ность проекта	уровень проекта
Высокая	Низкий	Большой	Низкая
Высокая	Низкий	Маленький	Очень низкая
Высокая	Высокий	Большой	Средняя
Высокая	Высокий	Маленький	Достаточно низкая
Низкая	Низкий	Большой	Низкая
Низкая	Низкий	Маленький	Очень низкая
Низкая	Высокий	Большой	Очень высокая
Низкая	Высокий	Маленький	Высокая

внимание, и это приводит к тому, что их потребности и предпочтения не соответ­ствуют готовой системе. Такое часто бывает в том случае, если бюджет проекта сильно ограничен и средства на обучение выделить невозможно (Bikson et al., 1985). Неясности и конфликты имеют место в любом проекте, однако они особен­но ярко проявляются в том случае, когда процесс плохо организован и практичес­ки неуправляем. Как показано на рис. 11.6, результаты неправильного управле­ния проектом могут быть следующими:

• перерасход средств;

• неожиданное затягивание сроков разработки;

• технические недостатки, ведущие к снижению производительности;

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

Насколько плохо обстоят дела с управлением проектами? Как правило, в част­ном секторе бюджетные и временные затраты недооцениваются наполовину. Огромное число проектов завершается созданием систем с неполной функцио­нальностью (дополнительные возможности планируется реализовать в следую­щих версиях). Около 30-40% всех проектов выходит из-под контроля и значи­тельно выходит за пределы запланированных бюджетов и графиков, созданные системы иногда имеют мало общего с тем, что указывается в заранее подготов­ленных спецификациях (Keil, Mann, and Rai, 2000). Почему же эти проекты так плохо управляются и что можно предпринять в подобных ситуациях? Здесь мы рассмотрим несколько возможностей.

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

Этот загадочный «человеко-месяц». Традиционной единицей измерения, ис­пользуемой системными проектировщиками для оценки временных затрат, яв­ляется человеко-месяц. Однако привлечение дополнительных сотрудников не всегда приводит к ускорению реализации проекта (Brooks, 1974). В отличие от простых процессов (например, уборки хлопка) анализ систем включает множе­ство процессов, которые выполняются последовательно и не могут протекать изолированно друг от друга, но требуют интенсивной коммуникации и обучения. Привлечение дополнительных трудовых резервов может замедлить процессы коммуникации, обучения и повысить расходы на координирование работы всех участников проекта. Для сравнения, представим себе, что произойдет, если пяте­рых зрителей добавить в команду профессиональных баскетболистов. Естествен­но, команда, состоящая только из профессионалов, будет играть гораздо лучше, чем такой смешанный коллектив.

Плохие новости распространяются медленно. Зачастую сотрудники, уча­ствующие в проекте, не сообщают высшему руководству о возникающих задерж­ках, ошибках и сбоях системы до тех пор, пока не становится слишком поздно (Keil and Robey, 2001). Классическим примером такой ситуации является проект под названием CONFIRM. В ходе его выполнения была разработана крупномас­штабная информационная система, призванная объединить отдельные системы заказа авиабилетов, бронирования номеров и аренды автомобилей. Проект фи­нансировался компаниями Hilton Hotels, Budget Rent-a-Car и Marriott Corporation и разрабатывался под руководством AMR Information Services, Inc., дочерней ком­пании American Airlines Corporation. Это был амбициозный, а также технически сложный проект, над его осуществлением работали около 500 сотрудников. Чле­ны команды разработчиков CONFIRM не доложили руководству вовремя о том, что проект начинает испытывать трудности из-за сложности координирования различных операций. Заказчики продолжали инвестировать средства в уже про­валившийся проект, потому что они не знали о существующих проблемах, свя­занных с базами данных, поддержкой принятия решений и совместимостью раз­личных технологий.

Man-month (человеко-месяц)

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

Трудности управления изменениями при внедрении корпоративных систем и реинжиниринге бизнес-процессов

Учитывая трудности, с которыми приходится сталкиваться при внедрении но­вых систем, нет ничего удивительного в том, что велика вероятность сбоев проек­тов реинжиниринга бизнес-процессов и корпоративных систем. Дело в том, что в этом случае предполагаются масштабные изменения в структуре и работе орга­низации, а также замена устаревших систем, поддерживающих выполнение мно­жества бизнес-процессов (Lloyd, Dewar, and Pooley, 1999). Результаты многих исследований показали, что 70% всех проектов по реинжинирингу бизнес-про­цессов потерпели крах. Более того, большое число проектов, связанных с плани­рованием ресурсов предприятий, так и не было внедрено или не принесло жела­емых результатов даже спустя три года после их запуска (Gilloly, 1998).

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

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

Слияние предприятий: что происходит с информационными системами?

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

Хотя некоторые компании, такие как General Electric, успешно провели доволь­но много операций по слиянию и приобрели множество других предприятий, ис­следования показывают, что более 70% таких операций снижает стоимость акций компаний, приводя в дальнейшем к изъятию капиталовложений (Braxton Asso-

dates, 1997; Economist, 1997). Основной причиной таких неудач являются слож­ности, возникающие при объединении различных корпоративных информацион­ных систем. На процесс объединения компании большое влияние оказывают их организационные характеристики и информационная инфраструктура. Комби­нирование информационных систем двух различных компаний обычно требует значительных организационных изменений и внедрения сложных системных проектов; если при этом все процессы не будут находиться под контролем, то в результате может получиться мешанина из старых и новых систем, несовмести­мых друг с другом. В таком случае ожидаемые выгоды вряд ли будут получены, и более того, в результате неудачного слияния компания не сможет нормально функционировать и потеряет своих клиентов.

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

11.3. Управление внедрением

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

Управление факторами риска

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

Управление технической сложностью

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

1:11111311111111 Компания TransCanada: управление слиянием

Компания TransCanada Pipelines является ведущей компанией — транспор­тировщиком газа в Северной Америке, ежедневно переправляя 275 млн м³ природного газа через Канаду и Соединенные Штаты. Компания также яви­лась инициатором самого крупного слияния за всю историю Канады, когда 1 июля 1998 г. объединились TransCanada PipeLines Ltd. и Nova Corp. Оба пред­приятия являлись гигантами канадской газовой индустрии. Получившаяся в результате компания (также носящая название TransCanada PipeLines Ltd. и расположенная в Калгари) обладала годовым доходом в 17 млрд канадских долларов и насчитывала 4500 работников. Самым сложным для Русса Уэллса (Russ Wells), главного информационного менеджера компании TransCanada, было объединить информационные структуры обеих компаний.

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

Хотя обе компании использовали одинаковые программные средства для настольных систем, таких как Microsoft Office и Windows NT, их информацион­ные инфраструктуры значительно отличались друг от друга. Компания Nova использовала программы Oracle, Microsoft Internet Explorer, Windows NT и Visual Basic и находилась в процессе внедрения программного комплекса от компа­нии SAP. Компания TransCanada использовала Forte и Java-приложения от Sun Microsystems, а также программы от таких фирм, как Sybase, Novell и Netscape Communications. У компании TransCanada не было единой информационной корпоративной системы, вместо этого она использовала в каждой области отдельные приложения.

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

Инструменты формального планирования и контроля

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

Данные технологии управления проектом помогают менеджерам^ в нахожде­нии слабых звеньев проекта, а также в определении того, какое влияние возника-

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

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

Уэллс старался как можно быстрее создать план реорганизаций, использу­ющий преимущества обеих компаний и их информационных систем, а также сохранить максимальное число сотрудников на своих рабочих местах. Кон­сультанты, ранее работавшие с Nova, по-прежнему решали поставленные за­дачи, но перешли под управление внутреннего отдела компании TransCanada. Фирма TransCanada предпочитала собственные стратегические и архитек­турные решения. Обеспечение компании компьютерным и телекоммуникаци­онным оборудованием было поручено фирме IBM, которая ранее занималась этим в Nova. Новая информационная структура была создана в феврале 1999 г. Основной урок, который Уэллс и TransCanada вынесли из этого процесса, — это необходимость информирования сотрудников обо всех стадиях выполне­ния проекта.

Руководство компании TransCanada пришло к выводу о том, что новая ин­формационная инфраструктура работает отлично. Компания смогла реализо­вать несколько важных проектов вовремя, при этом затраты в 2000 г. по срав­нению с 1998 г. снизились на 12,5%.

Информация к размышлению. Укажите управленческие, организацион­ные и технические аспекты слияния компаний TransCanada и Nova? Оцените роль Уэллса в этом процессе.

Источники: Kathleen Melymuka. «Rules of Engagement», Computerwor/d, July 24, 2000; «Cisco and TransCanada», Cisco Systems, January 24, 2001.

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

Вовлечение пользователей в проект и преодоление их сопротивления

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

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

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

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

Если использование новой системы является делом добровольным, пользова­тели могут отказаться с ней работать; в случае обязательного перехода на новое программное обеспечение пользовательское сопротивление может вылиться в по­вышенное число ошибок, сбоев и повторов отдельных операций, при этом возмож­ны даже случаи сознательного саботажа. Поэтому стратегия внедрения должна не только вовлекать пользователей в этот процесс, но и обращать внимание на «про-тивовнедрение» (Keen, 1981). Противовнедрение — это предупредительная страте­гия, направленная против внедрения новой системы или инноваций в организации. Стратегии, используемые для преодоления негативной реакции пользовате­лей, включают в себя привлечение пользователей к процессу внедрения (позво­ляющее к тому же улучшить параметры системы), их обучение, приказы руковод-

Internal integration tools (инструменты внутренней интеграции)

Технология управления проектом, позволяющая убедиться, что команда спе­циалистов работает как «единый организм». Formal planning tools (инструменты формального планирования)

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

Formal control tools (инструменты формального контроля)

Методика управления проектом, помогающая отслеживать прогресс выпол­нения проекта и отмечать достижение поставленных целей. External integration tools (инструменты внешней интеграции) Технология управления проектом, устанавливающая взаимосвязь между ко­мандой разработчиков и пользователями на всех уровнях организации. Counterimplementation (противовнедрение)

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

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

Разработка проекта для организации

Поскольку целью новой системы является повышение эффективности работы организации, процесс разработки такой системы должен учитывать пути пере­стройки организации, связанные с внедрением нового программного обеспече­ния, компьютерных сетей и интернет-приложений. Все изменения в процедурах, рабочих функциях, организационной структуре, ее взаимосвязях и поведении должны быть заранее запланированы. Когда технологические новшества приво­дят к непредвиденным последствиям, необходима определенная «импровизация», позволяющая извлечь выгоду из открывающихся новых возможностей. Специа­листы по информационным системам, менеджеры и конечные пользователи долж­ны творчески относиться к своим новым обязанностям, не ограничиваясь про­стым следованием правилам (Orlikowski, Hofman, 1997; Markus, Benjamin, 1997). В табл. 11.5 показаны организационные аспекты, которые должны учитываться в процессах планирования и внедрения большинства новых систем.

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

Учет человеческого фактора

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

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

Таблица 11.5

Организационные факторы в системном планировании и внедрении

Вовлечение пользователей в процесс создания системы

Методика работы

Контроль соблюдения стандартов и производительности

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

Процедуры разрешения трудовых споров

Здоровье и безопасность $

Соответствие государственным постановлениям и требованиям

Organizational impact analysis (анализ влияния на организацию)

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

Ergonomics (эргономика)

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

и вопросы технологии выполнения работ, обеспечения безопасности сотрудни­ков и проектирования пользовательских интерфейсов. Влияние системы на рабо­чее окружение и методики выполнения работ должно быть тщательно оценено. Заслуживающее внимания исследование, проведенное Администрацией социаль­ного обеспечения США, показало, что оценщики ущерба, имеющие интерактив­ный доступ к данным об авариях, испытывают в работе больший стресс, чем те, которые получают информационные сводки по телетайпу. Несмотря на то что интерактивный интерфейс работает быстрее и обладает большей функциональ­ностью по сравнению с телетайпом, пользователи относились к нему отрица­тельно. Представители, работающие с ним, могли обслуживать большее число клиентов в течение рабочего дня, что изменило условия их работы. Реструктури­зация работы — появление новых задач, повышение требований к качеству работы и производительности — обладает гораздо большим влиянием, чем новая техно­логия сама по себе (Turner, 1984).

Социотехнический дизайн

Большинство современных технологий создания информационных систем учи­тывают предпочтения пользователей, но заставляют их играть крайне пассивную роль по отношению к таким группам, как технические специалисты и менеджеры. Манифест, провозглашенный Европейским социал-демократическим рабочим движением, призывает пользователей играть более активную роль в определении места информационных систем в их рабочем окружении (Clement, Van den Bes-selaar, 1993).

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

Sociotechnica! design (социотехнический дизайн)

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

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

Управление проектами четвертого поколения

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

Дата добавления: 2015-04-29