Как обеспечить качество ИТ-проекта со стороны заказчика

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

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

Главным заинтересованным участником любого проекта вне­дрения ИС является, конечно, его инициатор — заказчик. Но вопросы правильного поведения заказчика для повышения ка­чества проекта часто остаются за кадром процесса внедрения ИС (рис. 2.12).

Информационная система (ИС) должна быть отражением именно бизнес-потребностей заказчика. И почти всегда внедрен­ная ИС является компромиссом между потребностями всех ее по­требителей и возможностями ее внедренцев и разработчиков. ИС — это не только процедуры,, «софт и железо», но и ее пользо­ватели, на каком бы уровне оргструктуры компании они ни ра­ботали.

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

А важнейшей чертой ИТ-проекта является наличие четко сфор­мулированной цели. Цель любой автоматизации — решение ка­ких-то проблем, поэтому их точное определение и есть та отправ­ная точка, с которой начинается автоматизация.

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

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

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

Наработанные процессы — это главная интеллектуальная соб­ственность предприятия и проявление его конкурентного отли­чия. Но здесь важно не допустить типичных ошибок (рис. 2.14).

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

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

В этих случаях заказчика может подстерегать еще одна серьез­ная проблема снижения качества проекта — наличие отката.

В этом случае количество неудачных проектов возрастает по сравнению с абсолютно честным внедрением ИТ-решений.

Дело в том, что человек, получивший откат, волей-неволей ста­новится заложником ситуации, да и в определенной степени ком­пании-поставщика.

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

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

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

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

В результате такой автоматизации могут быть автоматизиро­ваны какие-то службы по отдельности, но КИСУ так не постро-

ишь. Именно поэтому функции заказчика нецелесообразно де­легировать ниже уровня руководителя предприятия либо его за­местителей, потому что это ставит под угрозу реализацию проек­та (см. рис. 2.12).

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

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

Если заинтересованность в проекте со стороны руководства от­сутствует, то вероятность его успеха стремится к нулю.

Почему?

А потому, что основной задачей ИТ-технологии не является по­вышение эффективности труда работников.

Чаще всего подобные изменения — цель руководителя или соб­ственника, а самим сотрудникам это приносит дополнительную головную боль.

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

Обычно они сводятся к повышению управляемости предприя­тия и возможности расширения бизнеса. Но рядовые сотрудни­ки, за редким исключением, встречают такие перемены всегда в штыки.

Почему?

По крайней мере по двум причинам.

Первая — сложившаяся в компании система учета и докумен­тооборота, которая представляется всем работникам единствен­но возможной, а потому не подлежащей пересмотру.

И поэтому от внедряемой системы часто требуют полного со­ответствия всем, даже абсурдным условностям, к которым люди уже привыкли.

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

Разумеется, рост объема работы не может нравиться ни рядо­вым работникам, ни финансистам, настроившимся на экономию и сокращение персонала.

Так что же делать? Выделяют следующие основные факторы успеха внедрения системы (рис. 2.16).

Прокомментируем основные из них.

1. Проведение предварительного обследования и последующе­го моделирования необходимых бизнес-процессов. Работу эту проводят с помощью консультантов.

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

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

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

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

6. Подготовленный менеджер проекта. Именно он должен со­гласовать на самом высоком уровне максимально подроб­ный план-график проекта с финансовой ответственностью заказчика за задержку или срыв его выполнения.

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

Именно поэтому «правильное» ТЗ — ключ к решению этой про­блемы (см. рис. 2.16).

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

Обычно такие проблемы преодолеваются только волевым ре­шением руководства.

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

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

Внешний консультант — это всегда как минимум свежий взгляд на проблему (см. рис. 2.17),

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

Удовлетворенность заказчика, как мы видим, зависит не толь­ко от профессионализма внедренцев, но и от профессионализма самих клиентов.

Если люди не хотят или не могут учиться работать в ИС, то тут уж как ни внедряй, все равно криво выйдет.

Именно поэтому подбор команды проекта со стороны заказ­чика всегда порождает массу внутренних проблем. Выбор прак­тически всегда идет только из существующих сотрудников заказ­чика, что:

• ограничивает круг возможных кандидатов;

• приводит к выделению не ключевых, а «частично свобод­ных» специалистов;

• приводит к нежеланию заказчика выделять сотрудников под нужды проекта полностью — в результате ключевые фигу­ры занимаются совмещением работы в проекте с другими обязанностями, что часто приводит к печальным послед­ствиям.

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

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

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

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

Каждая из сторон, естественно, относится к этому процессу не­гативно, но жизнь есть жизнь!

В качестве управления этим процессом можно рекомендовать включать в соглашение о проектной группе пункт «о непереманивании» и четко указывать роли исполнителей.

Соглашение о проектной группе имеет статус приложения к до­говору и начинает обсуждаться с заказчиком либо до контракта, либо параллельно с ним.