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

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

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

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

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

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

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

⇐ Предыдущая96979899100101102103104105Следующая ⇒

Поделиться:

Воспользуйтесь поиском по сайту: