Опыт управления проектами внедрения, эксплуатации и модернизации корпоративных информационных систем Текст научной статьи по специальности «Экономика и бизнес»

Удк 338.24.01: 65.011.56

опыт управления проектами внедрения, эксплуатации и модернизации корпоративных информационных систем

Л. Ю. СУДАКОВА, соискатель кафедры экономики и менеджмента Е-mail: avocadus@gmail. com Московский городской педагогический университет

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

Ключевые слова: информационные технологии (ИТ), программный менеджер (руководитель проекта), опыт управления, организационное управление ИТ-проектом, корпоративная информационная система.

Формально процессы разработки, испытаний (тестирования), внедрения, сдачи—приемки в эксплуатацию, эксплуатации и модернизации корпоративных информационных систем (КИС) и их компонентов излагаются в ГОСТах, руководящих документах по стандартизации (содержат методические указания), ряде признанных зарубежных методологий (ITIL, RUP, OUM и др.). Вместе с тем жизнь вносит свои коррективы и требует учета накопленного опыта в этой сфере. Кстати, этого же требуют и методологии совершенствования качества работы предприятий, базовой для которых является методология, содержащаяся в стандарте ISO 9000. Она определяет, как достичь непрерывного совершенствования производственных процессов.

Существует множество источников, авторы которых излагают свой личный, очень ценный опыт

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

— организационно-технологическом (относится к технологии проведения работ);

— организационно-личностном.

Организационно-технологический срез

1. Проблемы. В ходе анализа опыта внедрения информационных технологий (ИТ) и КИС в систему управления современными организациями были выявлены следующие основные проблемы этого процесса.

Руководителям ИТ-проектов хорошо знакомы ситуации, когда прекрасно спланированный процесс не укладывается во временные рамки. Несмотря на то, что сроки были определены с запасом, одни модули «забирают» все доступные ресурсы, другие сразу после появления на свет удаляются за ненадобностью, а постоянные изменения требований окончательно разрушают проект [6]. Факторы, которые переводят проекты в разряд безнадежных [14]:

1) административные проблемы:

— хаотичный процесс разработки;

— обилие политики и принятие решений, затрагивающих чьи-то должностные обязанности;

— устаревшие практики и стандарты;

— чрезмерный оптимизм;

— «непрозрачность» работ для заказчика;

— постоянно изменяющиеся требования;

— затрудненные коммуникации; слабая мотивация сотрудников;

2) проблемы проектирования:

— концептуальная неполнота и противоречивость;

— отсутствие единой терминологии;

— недостаточная полнота функциональной совместимости модулей;

3) проблемы разработки и тестирования:

— повторное изобретение известных решений;

— игнорирование требования удобства использования;

— проблемы с документацией;

— плохо налаженное тестирование.

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

— коренная модернизация отделов стандартов качества и технической документации;

— внедрение новых стандартов и технологий;

— написание собственных методик [6].

Проблемы изменения требований к системе

оказывают еще более негативное влияние на проект при затрудненности коммуникации из-за территориальной распределенности членов команд заказчика и исполнителя, когда основными средствами взаимодействия становятся совещания и рабочая документация проекта [6].

2. Опыт работ по внедрению. Готовность компании к внедрению ИТ определяется следующими факторами:

— насколько структурированы ее бизнес-процессы;

—как сформулирована учетная политика;

— как формализован план счетов (единый как для целей учета, так и для целей разработки бюджета).

Если этого нет, как правило, автоматизацию приходится начинать с бизнес-консалтинга и реинжиниринга бизнес-процессов, что существенно

усложняет и удлиняет работу по внедрению, а также увеличивает ее стоимость [25].

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

Одновременно во всех фазах проекта следует просчитывать риски. Выбор системы должен производиться с учетом перспектив развития организации, планов роста и развития бизнеса. При этом КИС должна соответствовать финансовым возможностям. Масштабируемые решения позволяют сохранить внесенные ранее инвестиции [25].

Внедрение собственными силами после соответствующего обучения — достаточно результативная модель при выполнении следующих условий:

— выделение рабочего времени функциональных экспертов автоматизируемой бизнес-области;

— обращение к консультанту для «точечного консалтинга» при возникновении сложных вопросов;

— в компании действует большое и развитое подразделение ИС, есть квалифицированные кадры и осуществляется программа повышения их профессиональных навыков [10].

Внедрение системы следует начинать с более простых компонентов с меньшей степенью риска. Например с управления финансами. Потом переходить к материально-техническому управлению запасами, закупкам, бухучету и т. д. [7].

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

При внедрении аналитических подсистем наиболее естественная последовательность внедрения бывает такой:

— сначала строится хранилище данных, чтобы объединить и нормализовать информацию;

— потом создается система аналитической обработки в реальном масштабе времени (OLAP) для проведения анализа, создания отчетов, разработки бюджета [22].

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

Внедрение КИС может быть успешным только в том случае, если оно не будет для компании и консультантов самоцелью. Основная задача — не установить и настроить те или иные модули, а автоматизировать определенные бизнес-процессы. Только тогда можно обеспечить прочную связь между началом и окончанием проекта, который может продолжаться несколько лет и состоять из множества этапов.

Если возможно, часть этапов лучше реализовы-вать на основе типовых услуг, имеющих:

— вполне определенную стоимость;

— сроки исполнения;

— заранее известный результат.

Разбивку на этапы следует производить таким образом, чтобы происходило наращивание возможностей КИС в виде появления новых законченных и самодостаточных звеньев. То есть после этапа автоматизации бухгалтерии ее персонал должен работать в системе независимо от того, автоматизировано ли, например, производство. Каждая задача обязана иметь четкий критерий завершения и успешности и быть поставлена таким образом, чтобы решить ее можно было в обозримый срок, по возможности — в течение полугода. Если же она будет решаться на протяжении трех лет, ситуация изменится быстрее, чем с этой задачей будет покончено. Следовательно, требуется обеспечивать устойчивое финансирование и исключать его зависимость от противоречий между руководителями служб, чтобы проекты информатизации не затягивались [20].

Одна из компаний — исполнителей работ при внедрении интернет-решений (протоколы и веб-технологии: порталы, сайты, механизмы поиска, механизмы публикации и подписки) для построения корпоративных сетей руководствовалась принципом трех троек:

— нормальный интернет-проект должен быть внедрен не больше чем за 3—6 мес.;

— его необходимо реализовать силами не более трех чел.;

— проект должен стоить не дороже 300 тыс. долл.

Если проект выходит за эти рамки, он прекращается. Этот принцип позволял очень быстро реализовывать проекты и ощущать отдачу.

Непосредственно рекомендуемый процесс внедрения интернет-решений включает пять частей:

— разъяснение их преимуществ внутри компании;

— определение степени готовности к их применению;

— создание списка интернет-инициатив в компании;

— их приоритезация;

— непосредственное внедрение тех или иных интернет-проектов.

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

Для успешного завершения проекта заказчику следует обратить внимание еще на ряд моментов. Основная опасность неэффективного внедрения заключается в том, что проект может «уйти в сторону». Цель бухгалтерии способна не совпадать с целью финансового управления. И та, и другая могут отличаться от цели директора или начальника ИС. Здесь необходимо соблюсти разумный баланс [15].

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

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

Axapta в торговом доме «Перекресток» практически полностью были написаны складской модуль и вся логистика. Для сопровождения этого продукта была создана команда, составляющая порядка 20 сотрудников ИТ-департамента торгового дома [20].

В холдинговых распределенных компаниях обязательно требуется проводить оценку целесообразности централизации решения определенных задач. Так, в нефтяном холдинге из двух нефтедобывающих и девяти сервисных предприятий была создана фирма «ТНК-Бизнессервис» для централизованного оказания услуг по ведению бухгалтерского и налогового учета. Это позволило провести автоматизацию не девяти, а только одной бизнес-единицы. Тем самым были достигнуты следующие положительные результаты:

— исключены параллельные внедрения;

— сокращены затраты на вычислительную инфраструктуру (все техническое решение обеспечивает один крупный сервер с единой базой данных);

— оптимизировано число рабочих мест;

— достигнуто упрощение методологического контроля за работой бухгалтеров, поскольку они находятся в одном здании [7].

Многие специалисты считают, что стандартными и, по возможности, простыми решениями можно охватить до 80 и даже 90 % имеющихся ресурсов [16]. Это способствует сосредоточению способностей персонала ИС на тех аспектах, которые выделят организацию на фоне других с целью получения дополнительных конкурентных преимуществ.

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

Хорошим проектным решением являются:

— стандарт на оформление программных форм;

— нормативы на количество и размеры информационных и управляющих элементов, характеристики цветовой гаммы и т. п.

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

Одним из показателей зрелости ИТ-компании, как известно, является наличие у нее стандарта тестирования, где представлена функциональная модель тестирования, изготовлены тестовые классы, подсистемы, скрипты, инструменты, документация по проведению тестирования, определены сроки, роли и обязанности участников [6].

Успех проекта напрямую зависит от вовлеченности заказчика в процессы сбора и детализации требований к программному обеспечению (ПО) и в процесс тестирования. Если у функциональных экспертов заказчика не хватает времени на участие в тестировании, целесообразна приостановка проекта внедрения ПО до момента его появления. При этом важно фиксировать и документировать ранее полученные результаты.

3. Опыт эксплуатации. После сдачи КИС в эксплуатацию, как правило, поле для работы внешних консультантов и применения творческих способностей собственного персонала ИС остается широким и не ограничивается настройкой системы, созданием новых отчетов, исправлением допущенных ошибок. Любой бизнес имеет свойство расти, развиваться, а иногда кардинально меняться. Необходимо заниматься уточнением перечня работ последующих этапов, в том числе с учетом отзывов пользователей. Может потребоваться модернизация КИС (возможность проведения которой должна предусматриваться еще на стадии ее проектирования) путем изменения многих проведенных построений как на уровне ключевых показателей, так и на уровне самой системы. Соответственно необходимо пересматривать:

— стратегию;

— цели;

— критерии их достижения;

— бизнес-процессы и способы их автоматизации.

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

До сих пор идут споры, что дешевле — полностью полагаться на поддержку специалистов разработчика ПО (или его партнеров), час работы которых стоит от 25 долл., или максимально рассчитывать на собственные силы в эксплуатации покупного решения [8]. Как правило, истина лежит посередине. В первом случае, чтобы оставаться в рамках бюджета, все равно надо иметь своих специалистов, которые могли бы выявить возникшие проблемы и грамотно сформулировать вопросы по ним. Без этого на устранение проблем потребуется гораздо больше времени, а следовательно — затрат.

По мнению специалистов [8], если автоматизированные процессы отлажены и стабильны (расчет заработной платы, кадровый учет), их можно смело передавать на внешнюю поддержку. Если же они требуют частой перенастройки (учет заработной платы с множеством видов начислений и удержаний), такая поддержка может оказаться чрезмерно дорогой из-за частых обращений к поставщику услуг поддержки. Ее лучше осуществлять собственными силами. В случае же, если бизнес-процесс меняется кардинально и требуется доработка системы, такие задачи должны решаться при поддержке квалифицированных консультантов (собственная ИТ-служба не всегда способна справиться со сложными доработками).

Руководителям ИС свойственно занижать важность финансовой составляющей решения и акцентировать внимание на необходимости снижения риска. Хотя это и обеспечивает высокий уровень защищенности бизнеса, но часто не является лучшим способом использования ресурсов. Проблема рассматривается бинарно: либо рискованное решение, либо абсолютно нерискованное, чем исключается эффективное управление рисками на основе связи с затратами. Процесс принятия решения становится односторонне плоским — внедрять дорогое решение или оставлять бизнес незащищенным. На самом же деле чаще всего увеличение риска всего

на несколько процентов в разы снижает стоимость решения [11].

Неоправданные расходы возникают, как правило, из-за плохого взаимодействия между руководителем ИС и менеджментом по поводу принимаемого риска. Даже при самых наилучших побуждениях они могут очень быстро выйти за пределы бюджета. Как показывает практика, правильная постановка вопросов, оценки реального риска и здравый смысл могут сильно помочь в организации успешной работы директора ИС с руководством компании в направлении снижения риска и стоимости. Руководство компании должно обращать внимание на необходимость принятия оптимальных решений, а в обязанности руководителя ИС следует внести пункт об оказании ему помощи в поиске возможных решений различных вопросов, связанных с ИС. Ведь ИС создана и финансируется для того, чтобы помогать бизнесу, в том числе путем предоставления данных о реальной стоимости услуги [11].

В ходе эксплуатации самой острой проблемой называют переход на новую версию системы. Приемлемая совместимость версий достигается со временем. Поэтому переход на новую версию после выхода примерно через год полного пакета техподдержки (обычно второй крупный пакет программных «заплаток») существенно снижает риск сбоев. Одно из неизбежных зол — «карусель «заплаток», первая из которых закрывает «дыру», а вторая, закрывая следующую, возвращая первую. Иногда делают ошибки и системные администраторы, пренебрегая некоторыми указаниями инструкций по установке «заплаток». Часть компаний вообще старается держаться старой привычной версии, до тех пор пока она официально не снимается с «фирменной» техподдержки, продолжая обновляться в соответствии с изменяющимся законодательством и прочими реалиями жизни [27].

Вторая проблема возникает, когда в новой версии меняется интерфейс системы (например последовательность кнопок, на которые нажимает пользователь). Должно пройти время, пока он приобретет новый навык [27].

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

ращении к старым базам данных, которые следует хранить не менее 2—5 лет [27].

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

— неверно введенная информация;

— неправильно выбранный формат данных (нужно было учитывать два знака после запятой, а завели только один) и т. п.

Многие специалисты, занимающиеся предметными задачами (конструкторы, начальники цехов, технологи), не доверяя системе, зачастую пытаются разобраться в ее работе, схемах преобразования, конкретных алгоритмах, которые закрыты разработчиком. Предоставление им такой возможности означает выбор тупикового пути в виде попыток доказывать то, что уже давно доказано, т. е. бесполезной траты рабочего времени ценных сотрудников. Здесь тоже нужны подчиняющие директивы руководства. Системы, созданные группой внедрения, должны далее на согласование идти не по горизонтали, а к высшему руководству, которое обязано понимать проблемы и способы их решения. Иначе любая разработка потонет в горизонтальных согласованиях, на проект уйдут годы [8].

Вывод один — эксплуатировать и развивать КИС, которая затрагивает организацию в целом, не прибегая к методу принуждения сверху, невозможно. Для этого нужна воля руководства.

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

Организационно-личностный срез

1. Административные аспекты организации процесса внедрения КИС. Существует точка зрения, что более 50 % успеха проекта внедрения КИС — это административный ресурс со стороны заказчика, а не квалификация консультанта и не сама система. Более 50 % проблем обычно связано с организацией проекта, поскольку к 2005—2010 гг. функциональность систем, как правило, стала достаточной, а квалификация консультантов — высокой [10].

Очевидно, что ИТ-структуры становятся более успешными только при выделении в отдельный блок под руководством начальника информационной службы (ИС), который управляет процессом информатизации, будучи равноправным членом управленческой команды организации. Если этого нет, то ИТ-структура всегда будет рассматриваться как обслуживающее подразделение, а не как равноправный партнер бизнеса [5]. Например, если она подчинена главному инженеру, будут выполняться лишь отдельные работы для его служб, но на бизнес это повлияет мало [2].

Следует понимать, что КИС внедряется не для оптимизации работы подразделений—бухгалтерии, склада, отдела кадров, а для решения бизнес-задач. Поэтому и решения о финансировании проектов внедрения ИТ должны приниматься на соответствующем уровне — руководства и собственников компаний [17]. Задачи руководителя ИС:

— постоянно отслеживать максимально широкий спектр технологических инноваций на рынке;

— проецировать их на реалии конкретного бизнеса в конкретном окружении;

— на этой основе систематически внедрять в сознание руководства идеи о пользе (только на фоне сопутствующих рисков) внедрения тех или иных технологий в данной организации в данное время.

Консультации с руководителями бизнес-направлений позволяют снижать риски [21].

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

— отдел планирования информационных технологий;

— отдел взаимодействия с подрядчиками;

— отдел эксплуатации развернутых систем;

— отдел внедрения систем управления [7].

Важно, чтобы сложный и долгосрочный проект

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

— четко разделять уровни задач и проблем,

— формулировать приоритеты,

— ставить задачи подразделениям,

— мотивировать людей на их выполнение [2, 6].

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

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

Обычно самыми эффективными бывают группы смешанного состава не более чем из 10 чел. В группу целесообразно включить:

— менеджеров подразделений, в которых предвидятся наибольше изменения;

— одного или двух технических специалистов;

— внешнего консультанта, который владеет методологией, хотя может и не знать тонкостей производственного процесса;

— преданного сотрудника, которому доверяет руководство;

— представителей заказчиков, если возможно;

— представителей высшего руководства.

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

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

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

—не хочет терять власть;

— не уверен в собственных заместителях, и тем более — в среднем звене управленцев;

— не умеет отделять главное от второстепенного.

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

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

— фиксированной ответственности за результаты процессов;

— подотчетности по управлению ключевыми видами деятельности;

— перенаправления времени и мотивации руководителей на реальные ценности, а не на сохранение статуса-кво вверенных им подразделений.

Создаваемая за счет горизонтальных связей между подразделениями атмосфера сотрудничества в четко заданных рамках создает условия для эффективного применения нематериальных методов мотивации [12].

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

Эксплуатация КИС во многом зависит от сотрудников организации заказчика, не входящих в ИС, т. е. пользователей. Причем в большинстве случаев именно по повышению эффективности и качества работы этих пользователей судят о ее качестве и эффективности и о качестве работы информационной службы [1]. Вот почему после завершения каждого этапа внедрения КИС необходимо обучать сотрудников работе с новой версией ПО КИС (причем со сдачей зачетов) и обеспечивать ее техническую поддержку. Если этому не уделить достаточного внимания, могут возникать самые разные проблемные ситуации. Например, если сотрудники будут сканировать документы без распознавания их текста либо запоминать изображения без использования сжатия, сервер будет замусориваться гигабайтами документов [9].

Людям свойственно скрывать информацию, особенно добытую по личным каналам, которая является для них своего рода страховкой, гарантирующей их незаменимость. По разным причинам многие люди и группы людей в организации заинтересованы не столько в наличии оперативной, полной и достоверной информации, сколько в ее отсутствии. Отсутствие информации делает многие ресурсы просто невидимыми [3].

Поскольку регламент, процедуры лишают людей ощущения собственной уникальности и незаменимости, их внедрение зачастую тормозят и саботируют (явно или неявно) на всех уровнях иерархии компании [4]. Самым главным риском становится риск сопротивления переменам со стороны персонала. Для его снижения следует:

— применять убеждение, пропаганду перспективности и выгодности новых решений для каждого;

— дополнительно мотивировать активных участников внедрения;

— продумывать формы компенсации тем, для кого новые решения все-таки оказываются невыгодными.

Работники должны понимать:

— зачем они собирают информацию;

— как, кем и когда она будет использована;

— как это повлияет на их жизнь и жизнь компании в целом.

В противном случае вольно или невольно они будут саботировать этот процесс [2].

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

Участие в процессе реформирования и, главное, — в принятии решений сотрудников разных уровней из разных подразделений позволит всему коллективу почувствовать причастность к изменениям. Важно, чтобы такая группа была наделена реальными полномочиями и могла распоряжаться некоторыми ресурсами. Ее руководитель должен заботиться о снижении рисков, возникающих в процессе перемен (лучше всего путем построения системы начальных обстоятельств, не позволяющих персоналу совершать какие-то необратимые действия, в конце концов приводящие к успеху). Его искусство управления должно выражаться не в том, чтобы по каждому поводу одергивать сотрудников, а в умении создать ситуацию, в которой люди захотят работать с полной самоотдачей и смогут расти профессионально [23]. При введении инноваций административное давление следует использовать как можно реже, так как оно имеет негативные отдаленные последствия для компании [18].

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

переходного периода не слишком сказались на производительности труда и решении стратегических задач. Большое значение для успеха проводимых работ имеет информация о ходе перемен. Частый и честный обмен мнениями позволяет не только своевременно принимать необходимые решения, но и создает атмосферу открытости [23].

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

Часто причиной неуспеха проекта становится низкая квалификация технических и управленческих кадров заказчика и внедренческой компании. Квалификацию сотрудников ИС организации можно проверить, отправив их на стандартное тестирование в центр сертификации. Вместе с тем вне зависимости от уровня подготовки они лучше знают внутреннюю специфику своей организации, и к их мнениям стоит прислушиваться. Квалификацию партнера подтверждает разработчик ПО, авторизуя его как своего сертифицированного партнера [13, 19].

Использование дорогих профессионалов целесообразно только для тех организаций, которые вышли на достаточно высокий уровень финансовой и информационной зрелости. В типовых условиях больше подходит вариант, когда к одному такому специалисту прикрепляется от одного до трех «учеников». Большинство сотрудников заинтересовано в профессиональном росте и в повышении самооценки и возможности успешной карьеры. Руководителю проекта следует подумать, как обеспечить получение удовлетворения от сделанной работы и наладить атмосферу сотрудничества в команде [6].

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

3. Психологические аспекты цикла внедрения КИС. Основной фактор, определяющий успех, — настойчивость.

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

На второй фазе, характеризуемой спадом активности и оптимизма из-за первых неудач в проекте, появляется усталость, начинают проявляться непредусмотренные трудности и проблемы. Круг людей, поддерживающих проект, резко сокращается, на проект начинают косо смотреть. В этот момент велика опасность полного отказа от проекта или ограничения его до таких размеров, при которых теряется первоначальная идея. Этот период надо пережить с терпением и не терять оптимизма [18].

4. Технические аспекты организации процесса внедрения КИС. Как известно, среди проблем проектирования ключевое место занимает проблема отсутствия концептуальной целостности и непротиворечивости архитектуры. Поэтому важно назначить архитектора продукта, ответственного за все его стороны. Однако архитектор в своем стремлении обеспечить всю задаваемую функциональность может разрабатывать спецификации, которые неоднозначно воспринимаются разработчиками. В результате разрабатываемый ими программный код отрывается от технического задания, о чем аналитик и заказчик узнают последними. Системного аналитика и проектировщика нужно подключать к программированию, чтобы добиться их осведомленности (следовательно, и заказчика) о реальном положении дел, лучшей согласованности между архитектурой и реализацией, более действенной коммуникации. Именно так можно построить эффективную команду, а не просто группу разработчиков [6].

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

подавляются, приводит к отрицательному результату. Необходимо вовремя довести до архитекторов проблемы непосредственно кодирования, а менеджеры проектов должны представлять себе, как диаграммы, которые хорошо выглядят на бумаге, реализуются в коде. Поэтому наиболее эффективно привлечение многофункциональных специалистов, имеющих знания в нескольких смежных областях. Разработка программного обеспечения более сложна, многообразна и непредсказуема, чем конвейерное производство типовых моделей [6].

5. Аспекты взаимодействия заказчика и исполнителя в ходе внедрения КИС. Большое значение имеет достижение взаимопонимания между исполнителем и заказчиком. Различное понимание задач и ненужная напряженность во взаимоотношениях как на стадии принятия решения, так и на этапе его реализации ранее часто возникали по той простой причине, что руководители и сотрудники ИС организаций в 90 случаях из 100 — бывшие программисты, мало связанные с бизнесом [26]. Бывают случаи, когда исполнитель и заказчик просто по-человечески не находят общего языка, что может развалить весь проект [10]. Внешней команде-исполнителю необходимо приложить все усилия для создания атмосферы сотрудничества с персоналом ИС организации. Если с самого начала удается организовать взаимодействие так, чтобы специалисты ИС заказчика чувствовали себя главными сторонниками внедрения, шансы на успех резко возрастают. В качестве положительной мотивации выступают «возможность принести реальную пользу своей компании», «интересная работа», «новые знания» и «профессиональный рост» [13].

Не менее важен опыт работы исполнителя, поскольку при его накоплении он становится способным адекватно оценить трудозатраты и длительность каждого этапа. Работа исполнителя должна быть максимально открытой как в технологии, так и в ценообразовании с самого начала контактов. В традиционном представлении необходимо составление детального технического проекта и подробнейшей сметы всего ИТ-проекта (от подготовительных работ до конечного результата), чтобы с учетом заранее обговариваемой себестоимости специалистов определить стоимость ИТ-проекта по этапам работ [24].

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

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

Желательно, чтобы исполнитель принимал на себя ответственность за действия всех участников сквозного процесса предоставления программного продукта (сам разработчик/поставщик, партнеры по внедрению продукта, заказчик), особое внимание уделяя его заключительным этапам. Тем самым он бы отвечал не только за работу партнеров, но и непосредственно за оказание услуг заказчикам [26].

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

На основе практического опыта были сформулированы главные проблемы во внедрении, эксплуатации и модернизации корпоративных информационных систем (КИС), раскрыта роль руководства и персонала управления в создании и внедрении КИС со стороны как заказчиков, так и исполнителей работ, показано, как избежать трудностей, связанных с человеческим фактором. В системном виде изложены:

— порядок организации работ;

— возможности создания творческой атмосферы в коллективах;

— необходимость их мотивировки к достижению поставленных целей.

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

Список литературы

1. Алехин З. Как построить службу поддержки пользователей ИС. М. 2002.

2. Альтшулер И. Информация для руководителя: мифы и реальность // Intelligent Enterprise. 2002. № 17.

3. Альтшулер И. Компьютер как усилитель интеллекта. Материалы конференции «ИТ Стратегия» // Intelligent Enterprise. 2002. № 4.

4. Альтшулер И. Как интеллектуальное предприятие выбирает технологии. Материалы конференции «ИТ Стратегия» // Intelligent Enterprise. 2002. № 4.

5. Блох А. Инициатива в разработке ИТ-стратегии должна исходить от CIO. URL: http://www. itilitsm. ru.

6. Берлинский К. Как добиться успеха в безнадежных проектах. URL: http://www. osmag. ru.

7.БлохА. Сегодня безумие разрабатывать стратегию бизнеса в отрыве от ИТ-стратегии // Intelligent Enterprise. 2002. № 4.

8. Васильев В. Средняя температура по отрасли // Сетевой журнал. 2004. № 9.

9. Восканян М. Кладбище информационных технологий (анонимный рассказ двух ИТ-специалистов) // Intelligent enterprise. 2004. № 19.

10. Гликман Ф. Каждый проект—это скорее искусство, выстраивание уникальной цепочки человеческих отношений // Intelligent Enterprise. 2003. № 22.

11. Галкин Г. Бизнес-риски и ИТ-затраты // Intelligent enterprise. 2005. № 3.

12. Занин В. Процессное управление ИТ: как не «утопить» проект. URL: http://www. cnews. ru/ reviews/index. shtml?2007/03/01/238124_1.

13. Зотова Т. В поисках золотой середины // Сетевой журнал. 2003. № 7—8.

14. Иордан Э. Путь камикадзе. М.: Лори. 2001.

15. Кузьмин Ю. Опыт чужих ошибок // Intelligent Enterprise. 2003. № 6.

16. Коффи П. Преимущества ИТ // PC Week / RE. 2004. № 15.

17. КрасиловН. Методология внедрения должна соответствовать объему проекта // Intelligent Enterprise. 2003. № 11.

18. Кузнецов А. Лекарство от проектной эйфории — сдержанность в ожиданиях и здравый смысл в оценке сложности задач // Intelligent Enterprise. 2003. № 16.

19. Мартынов В. Эффект от внедрения — это решение бизнес-заказчика // Intelligent Enterprise.

2003. № 7.

20. Насколько серьезны сегодняшние потребности в ИТ у малого и среднего бизнеса // Сетевой журнал. 2003. № 3.

21. Педоренко А., Костяков С. Влиять на бизнес можно, только проявляя инициативу // Intelligent Enterprise. 2003. № 19.

22. Промышленные предприятия — ключевой потребитель ИТ: «круглый стол» // Сетевой журнал.

2004. № 9.

23. Седов В. Как реагировать на перемены? // Сетевой журнал. 2002. № 1.

24. Савельев C. // Сетевой журнал. 2002. № 5.

25. Цыценко А. Подводные камни внедрения, или Что нужно знать для принятия решения о внедрении ИТ // Intelligent Enterprise. 2003. № 4.

26. Шебек С. Как стать первым на ИТ-рынке // PC Week / RE. 2003. № 20.

27. URL: http://www.iemag.ru.