Олег Гейдаров, ИТ-директор ЗАО "Морская техника"

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

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

Стоя у "истоков"

Предположим, что руководство компании осознает свою роль владельца проекта и понимает двусмысленность ситуации с внедрением ИС. Оно готово посильно участвовать в их разрешении. Фактически в этом случае мы можем реабилитировать проектный подход. Просто рамки проекта должны быть расширены. Можно назвать новую задачу - "Переход к новому состоянию бизнес-процессов X, поддерживаемых информационной системой Y". Будем называть подобный проект расширенным проектом (РП). Внедрение информационной системы будет подпроектом данного проекта, и его этапы будут частями этапов общего проекта. Очевидно, что новая проектная команда, так или иначе, будет включать в себя руководство компании. Хорошо, если в компании существует на этот случай специальный орган (дирекция по развитию, например), однако в принципе достаточно вовлеченности топ-менеджмента в процесс.

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

Можно, конечно, списать данную ситуацию на отсутствие сформированной ИТ-цели, хотя в данном случае существовала даже ИТ-концепция, которой пытались следовать. В целом же компании не исповедуют проектный подход, и РП по определению не является проектом в чистом виде. Как следствие, в РП цели часто подменяются "истоками".

Даже в случае успешной диагностики "истоков" не следует ожидать появления списка целей для РП. Можно только определить некоторое "поле", на котором будут постоянно корректироваться требования к ИС. Также следует сформировать процедуры корректировки целей ИТ-системы.

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

1. Думали о другом. Иначе говоря, были некие цели, которые спровоцировали проект. Непосредственно к тому, что собираются делать сейчас, это не имеет никакого отношения. Основной риск тут заключается в опасности, что проект получит статус "бедного родственника". Подобная ситуация требует диалога с руководством, в особенности генеральным директором. По идее от такого проекта следует отказаться. Или, после возможных корректив, риски должно принять на себя руководство компании. Это никак не может быть делом ИТ.

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

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

4. Хотим снизить издержки. Это когда есть иллюзии относительно того, что внедрение информационной системы принесет прямую экономию. Такой пиар-ход любят нечистоплотные топ-менеджеры. В этом случае можно лишь напомнить собственникам, что снижение издержек - бизнес-задача. Успешно внедренная информационная система может создать иной уровень "качества" компании и дать возможность возникнуть неким новым идеям в бизнесе. Косвенно это может способствовать росту доходов или позволить закрепиться на определенном сегменте рынка. Однако IT-система принесет свои издержки, связанные с ее использованием. Даст ли это в целом положительный финансовый результат, когда он окупится? На все эти вопросы внятно могут ответить в тех самых хорошо организованных компаниях.

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

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

  • РП не прорисовывается или настолько далек от первоначального проекта, что продолжение работ просто невозможно;
  • РП в принципе соответствует ИТ-проекту или можно скорректировать ИТ-проект, не меняя существа вопроса.

Согласовать "видение"

Если проект продолжается, то прежде всего следует сформировать команду РП. Если для ИТ-проекта она, скорее всего, существует в том или ином виде, то на РП ее просто нет. Члены подобной "команды" вообще могут не воспринимать себя в контексте проекта. Фактически для РП членами команды будут не только стейкхолдеры проекта, но и все затронутые проектом специалисты.

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

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

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

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

3. Нечетко определенные роли подразделений и менеджеров на проекте, что автоматически внесет в проект хаос со всеми вытекающими последствиями. Скорее всего, это выльется в постоянные склоки.

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

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

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

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

  • Проблемы передела территории между подразделениями. Когда проект провоцирует подобные конфликты, в каждом случае руководству следует определиться с тем, что в компании происходит. Есть должности и функции или есть конкретные люди. В любом случае разводить спорщиков следует сверху.
  • Проблемы инициированы целями РП. Как правило, это ситуация, когда руководство само, преследуя цели РП, входит в конфликт со своим персоналом. Здесь бесполезно давать советы, ибо это уже бизнес-реинжиниринг. Тем не менее можно реализовать проект и в этом случае. Для ситуации "входа в бизнес" через ИТ так оно и будет. Главное - быть готовым к объемам издержек и понимать, куда их следует относить.

Поведя подобную балансировку интересов, мы в итоге должны получить более подготовленный к проекту бизнес. В зависимости от масштаба проекта это может быть очень короткий промежуток времени (неделя-две), а может год и более. Так или иначе, подготовка позволяет получить гораздо более "вменяемый" процесс внедрения.

Приведение к общему знаменателю

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

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

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

Очевидно, что наличие предварительной схемы проекта дает ряд преимуществ:

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

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

В нашем случае можно определить укрупненно фазы проекта и достигнуть по ним консенсуса внутри собственной команды. После этого структурировать работу с использованием понятия "витков" проекта:

  • выделить начальные фазы (виток 1), согласуясь текущим представлением о целях проекта в рамках проектных "истоков" РП. Это детерминированные фазы, над которыми можно работать, не сильно уклоняясь от проектной технологии. Здесь уместно договариваться о конкретных вещах;
  • на основании определенных начальных фаз проекта определить состав второго (прогнозируемого) витка. Здесь также применим проектный подход, но формализоваться будут не конкретные соглашения, а процедуры достижения новых соглашений, которые буду базироваться результатов первого витка. Можно сформировать и обсудить процедуры, по которым будет готовиться конкретика для этих фаз;
  • остаток должен уйти на третий (перспективный) виток. Проводить его анализ бессмысленно, поскольку в нем сосредоточены наиболее отдаленные фазы. Их выделение интересно в том плане, что поможет определить, на уточнение каких вопросов не стоит тратить времени. Рисунок - это спираль в три оборота с комментариями. Если рисовать ее, то придется повозиться.

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

Торг уместен

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

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

По всей видимости, проблема заключается в восприятии ценового фактора стороной внутреннего заказчика, а конкретно владельцами проекта. Иначе говоря, для владельцев проекта цена проекта - это:

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

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

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

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

  • "виток 1" (детерминированный) будет легко поддаваться стоимостной оценке. Поскольку его этапы хорошо формализованы, то с соблюдением стоимостей проекта не должно возникнуть никаких сложностей;
  • "виток 2" (прогнозируемый) будет подразумевать работу с ценовой вилкой. По мере выполнения проекта его фазы будут уточняться и переходить в "виток 1";
  • "виток 3", по всей вероятности, будет настолько отдален во времени, что необходимости в его непосредственном стоимостном оценивании просто нет. Скорее всего, его фазы окажутся за горизонтом краткосрочного финансового планирования.

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

Договариваться лучше заранее

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

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

Следует лишь выделить дополнительные особенности РП.

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

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

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

Представляется возможным разбить задачу эксплуатации внедренной системы на локальные подзадачи этапов или фаз. Таким образом, мы введем подзадачи как дополнительный параметр в этапы или фазы, а далее сможем применить методы те же методы что и для достижения консенсуса или управления ценой.

3. Команда РП - поскольку у РП проектная команда выходит за пределы IT-подразделения, то существует риск, что их формат работ на самом проекте будет удовлетворительным, а на внедренной системе они не будут реализовывать свою часть поддержки системы.

Данная проблема напрямую связана с ситуацией бизнес-реинжиниринга в процессе внедрения информационной системы. Следует вспомнить о том, что это одна из негативных особенностей РП. Мне представляется, что данная проблема связана с успешностью РП в целом.

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

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