Ребята, давайте жить дружно, или Конфликты внедрения информационных систем
Отклонение результатов от ожиданий
Информация для этой статьи накоплена и осмыслена в результате опыта компании «Инфарс», полученного в процессе работ по внедрению систем электронного документооборота в ряде проектных организаций.
В последнее время реже говорят о программных продуктах для автоматизации отдельных секторов бизнеса и чаще о корпоративных ИТ-проектах и о внедрении информационных систем. Многие издания публикуют статьи о реализации очередного проекта. В основном это рассказы об успехах, мало кто решается поведать миру об ошибках, просчетах и проблемах. А ведь проблемы есть, и из-за них вспыхивают серьезные конфликты, грозящие провалом проекта и расторжением отношений между добрыми партнерами. Но самое худшее в том, что последствия таких проблем не могут не сказываться на основной деятельности организации, решившейся на внедрение, и постепенно превращаются в настоящее бедствие.
Что же означает термин «внедрение», незаметно, но прочно вошедший в наш лексикон? В специальной литературе имеется ряд формулировок, наиболее подходящей из которых в данном контексте представляется следующая: «Внедрение — это сложный процесс интеграции информационной системы в финансово-управленческую деятельность компании». По сути же внедрение — это кардинальные перемены, нарушение устоявшегося порядка вещей и приемов работы, столкновение различных взглядов. И конфликты здесь неизбежны.
Внедрять информационные системы можно как силами собственных ИТ-подразделений, когда все работы от постановки задачи до собственно программной реализации выполняют ИТ-специалисты, так и с привлечением сторонних организаций. Сегодня речь пойдет о тех проектах, в которых обязательно участвуют внешние исполнители — консультанты по бизнес-моделированию, программисты, настраивающие функционал базового программного продукта под требования заказчика, и другие специалисты.
Данная статья — рассказ о том, с чем пришлось столкнуться нам, попытка привлечь внимание к наиболее существенным причинам, вызывающим конфликтные ситуации. Здесь нет готовых рецептов, следуя которым можно провести внедрение бесконфликтно. Это лишь призыв ко всем сторонам таких проектов научиться оценивать ситуацию с минимальным субъективизмом, научиться общаться конструктивно, не перекладывая вину друг на друга, и в результате снизить негативное влияние конфликтов любого рода на ход внедрения.
Не открою секрета, если скажу, что столкновение интересов исполнителя и заказчика — процесс естественный. Ведь чего хочет заказчик? В кратчайшие сроки получить как можно больший функционал, потратив при этом как можно меньше средств. А чего хочет исполнитель? Соблюсти рентабельность и получить «историю успеха».
Из этого естественного противостояния вытекают проблемы, которые мы постарались обобщить и сгруппировать. И вот что получилось. Самыми критичными являются конфликты, вызванные финансовыми аспектами, отставанием хода работ от графика и отклонением результатов от ожиданий. И конечно, успешному выполнению проекта мешает целый букет конфликтов личностного характера.
Финансовые конфликты
Разногласия, связанные с финансами, разрешить непросто. Тем не менее, понимая, на каких стадиях проекта формируется и корректируется стоимостная составляющая, можно снизить ее влияние на проект в целом. По крайней мере два узких места нам выявить удалось: финансовый конфликт может зародиться как на стадии формирования подробного технического задания, так и в процессе реализации проекта.
Как известно, на этапе принятия решения заказчиком и исполнителем определяется объем работ и соответствующие ему сроки и бюджет. Технический документ, регламентирующий создание системы, должен разрабатываться с учетом этих граничных условий. Попытка включить в него значительно больший функционал, ориентируясь при этом на сроки и бюджет, принятые на начальном этапе, неминуемо приведет к возникновению конфликта. Прежде всего такой вариант неприемлем для исполнителя, так как выводит проект за рамки допустимой рентабельности. Но он имеет печальные последствия и для заказчика, поскольку в результате превышаются сроки проекта и задерживается начало эксплуатации и отдачи системы. Как же с этим бороться? Можно попытаться разбить проект на этапы и своевременно корректировать ТЗ.
Но финансовая проблема может возникнуть и позже. Детальное понимание реальных задач системы, как правило, происходит уже в процессе исполнения проекта, когда часть функций теряет актуальность, но появляется необходимость реализации новых возможностей. Появление у заказчика новых пожеланий говорит о правильном ходе проекта, так как свидетельствует о том, что он увидел перспективу. Но это влечет за собой необходимость корректировать уже сделанное, требует дополнительных затрат и времени. Только заказчик не хочет платить за новый функционал, а исполнитель не хочет производить дополнительные работы за те же деньги, в результате чего вспыхивает конфликт.
Как этого избежать? С формальной точки зрения еще на стадии договора стороны должны определить процедуру корректировки требований к внедряемому решению и «закладывания» соответствующих бюджетных резервов.
А вот неформальное пожелание. Господа заказчики! Не забывайте, что по роду деятельности вы можете оказаться в роли исполнителя, старайтесь придерживаться требований к системе, зафиксированных в ТЗ! Господа исполнители! Откажитесь от джентльменских соглашений и не производите доработки функционала, не указанного в ТЗ, на добровольно-безвозмездной основе. Если же признано, что при начальном планировании проекта были допущены просчеты, то исправлять их и дорабатывать проект придется. Но при этом обязательно нужно оформить изменения и дополнения к техническому заданию и определить, какие элементы будут реализованы в рамках текущих работ, а какие — на последующих стадиях. Все произведенные доработки рекомендуем фиксировать в соответствующих протоколах (мы убедились, что впоследствии это играет огромную роль при разрешении спорных моментов), не забывая при этом корректировать календарный план работ.
 |
|
Нарушение графика работ
Если ход работ отстает от графика, это не обязательно означает, что выбор внедренческой компании был неудачным. Виновником этого может быть как исполнитель, так и заказчик.
Исполнитель, следуя законам коммерции, может сознательно скрыть от заказчика ограничения функциональности поставляемого программного обеспечения. В результате для реализации нужного функционала системы на базе такого ПО потребуется значительно больше усилий и времени, что неминуемо приведет к превышению сроков работ по проекту. Чтобы этого не случилось, IT-служба заказчика при выборе базового продукта должна произвести тщательный анализ рынка.
Сроки могут быть превышены и в том случае, если у исполнителя недостаточно персонала для выполнения работ по договору. Исполнитель может оказаться перегруженным, участвуя в нескольких проектах. Лишь грамотный менеджмент проекта со стороны исполнителя, постоянная координация работ и ресурсов позволит избежать срыва сроков. В противном случае неизбежны конфликты с заказчиком и соответствующие санкции.
Недостаточно квалифицированный персонал и отсутствие методики внедрения исполнителя также приводят к отставанию работ от графика. Правда, этот пункт сложно поддается оценке, ведь разработка и внедрение информационных систем — область неизведанная, многократно проверенных методик и опыта пока нет. А значит, нет и экспертов, способных объективно оценить уровень исполнителя.
Но нередко отклонение от сроков происходит из-за того, что работы тормозит заказчик — задерживает подачу запрошенных документов и согласование договорной и проектной документации, а также несвоевременно организует и проводит технические совещания, необходимые для решения спорных вопросов в процессе разработки системы, и приемку готового результата.
Предъявление заказчиком претензий без указания конкретных и однозначных несоответствий системы основному регламентирующему документу приводит к тому, что выяснение и обсуждение недочетов затягивается на длительное время, что отражается на сроках проекта в целом.
На сроки завершения проекта напрямую влияет такой фактор, как степень удовлетворенности заказчика результатом. Ведь если результат не отвечает ожиданиям заказчика, это грозит появлением множества требований по доработке, и, как следствие, увеличением продолжительности работ.
|
|
Отклонение результатов от ожиданий
Чаще всего конфликты подобного рода возникают из-за того, что клиенту не до конца понятны цель и задачи внедрения. Разве можно каким-либо образом оценить, насколько результат соответствует замыслу, и при этом остаться довольным, если изначально не существует критериев оценки готовой системы и границ данного проекта?
На собственном горьком опыте мы поняли, что клиенты из-за отсутствия опыта подобных работ не всегда могут самостоятельно определить реальные потребности организации и цели, которых хотят достичь в результате автоматизации. Задача разработчика — помочь клиентам с постановкой задачи. В противном случае ожидания клиента наверняка не оправдаются.
Результат может пострадать из-за ошибочного понимания заказчиком роли консультантов в процессе разработки и внедрения системы. Часто у компании-клиента возникает ощущение, что внедрение можно осуществить без участия сотрудников предприятия. Будущие пользователи изолируются от проекта. На этапе сбора исходной информации обследуемые сотрудники допускают оплошности, опуская существенные детали, касающиеся их работы, что отражается на конечном результате. На этапе создания и согласования регламентирующих документов (технического задания, технического проекта) специалисты заказчика зачастую относятся ко всему весьма формально, считая это односторонней задачей исполнителя. Неудивительно, что готовая система может не удовлетворять реальным потребностям заказчика, несмотря на то, что выполнена в соответствии с этими документами. В итоге — жалобы на сложность или неудобство программы.
Для регулярного взаимного мониторинга хода выполнения работ желательно также, чтобы заказчиком производилось тестирование промежуточных результатов, причем заранее должна быть оговорена форма представления и правила этого промежуточного тестирования.
Непосредственное участие представителей заказчика также требуется в процессе сдачи/приемки системы. Именно конечные пользователи должны произвести анализ всех режимов работы и составить список замечаний и пожеланий. И именно на основании этих данных система будет доводиться до желаемого результата. Но приемка и тестирование системы должны проводиться по специальным сценариям, которые должны разрабатываться совместно исполнителем и заказчиком.
В сценарии, помимо последовательности действий, должны быть описаны правила ранжирования выявленных в процессе приемки системы проблем. Заказчику нужно объяснить, что мелкие недочеты/ошибки неизбежны в новом продукте и что замечания можно ранжировать следующим образом:
- ошибки программирования, настройки;
- несоответствия основному регламентирующему;
- новые пожелания, выходящие за рамки согласованных регламентирующих документов.
Первый и второй пункты исправляются исполнителем в рамках договора и во время бесплатного годового сопровождения. Работы по третьему пункту производятся исполнителем по отдельным договорам на следующих этапах.
Нужно постараться развеять ошибочное убеждение заказчика в том, что настроенная единожды система будет самонастраиваться при изменениях в организации. Какой бы гибкой ни была система (а гибкой она считается, если имеются инструменты для наладки под новые условия без применения сложных методов типа программирования), участие человека обязательно. Заказчик должен подготовить специалистов, в обязанность которых входит поддержка и решение нештатных ситуаций в процессе эксплуатации системы.
Как победить информационную проблему при определении целей, постановке задачи и сборе данных? С заказчиком на этой стадии должны работать консультанты, обладающие высоким профессионализмом, хорошим знанием предметной области и чисто человеческой коммуникабельностью, позволяющей тактично добиться от обследуемого информации необходимой глубины. Разночтений, возникающих вследствие того, что участники проекта вкладывают в одно понятие разный смысл, можно постараться избежать путем создания понятийной базы, глоссария терминов.
Но одного профессионализма исполнителя недостаточно для успеха проекта, поэтому группу внедрения необходимо формировать из представителей как исполнителя, так и заказчика. Мы считаем обязательным условием включение в договор пункта о формировании рабочей группы. Причем предлагаем четко прописать ответственность каждого члена этой рабочей группы. Не исключается частичное освобождение от основных обязанностей специалистов заказчика (на усмотрение руководства возможна дополнительная мотивация).
Но недовольство конечным результатом может быть высказано кем-либо из участников рабочей группы, незаинтересованных в успехе внедрения. Несоответствие личных ценностей участников проекта ценностям фирмы вызывает неконструктивную критику системы, саботирование работы и, как следствие, увеличение сроков проекта. Причины этого разнообразны: нежелание повышения прозрачности своей деятельности, увеличение нагрузки, отсутствие должной квалификации и пр. Действительно, серьезное повышение нагрузки на сотрудников в процессе внедрения является объективной трудностью и, как говорилось выше, требует соответствующей мотивации.
|
|
Управление гневом
Наверняка многим хотя бы понаслышке знакомо понятие «Управление гневом». Да, всем нам нужно научиться справляться со своими эмоциями, ведь каковы бы ни были причины, решение любых конфликтов — это корректные переговоры, подтвержденные документами: контрактом, техническим заданием, техническим проектом, дополнительными соглашениями. А это означает, что подходить к составлению этих документов стороны проекта должны максимально ответственно, ведь чем меньше фраз, допускающих двусмысленность, чем больше спорных вопросов заранее оговорено, тем беднее почва для конфликта.
Закончить статью я хочу на оптимистичной ноте. Как говорится, не так страшен черт, как его малюют. И конфликт — это не провал проекта, а неотъемлемая составляющая, которая помогает переосмыслить задачи и скорректировать ожидания с учетом происходящих изменений. В процессе разрешения проблемы происходит взаимное «обучение» заказчика и исполнителя, каждая сторона открывает для себя что-то полезное. И если все участники проекта подходят к проблеме конструктивно, вполне возможно вовремя выявить причину конфликта, мобилизовать свои внутренние ресурсы, направить усилия в нужное русло и добиться успеха.
Начальник отела по работе с ключевыми клиентами Группы компаний «Инфарс».
|
|
