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

Ситуация первая.

О gold plating и вреде “экстра”

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

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

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

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

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

“Экстра” функциональность легко может принести вред. Возникнуть она может множеством способов, отнюдь не только приведенным выше, начиная от разработчика, решившего внести изменения в код, чтобы что-то улучшить и заканчивая заказчиком, попросившим недокументированные изменения. Вред от нее также может быть разнообразным. От отказа в обслуживании по договору, как в приведенном примере, до срыва сроков и увеличения бюджета. Хотя в примере и рассказывается про дополнительную (экстра) функциональность, вред может нанести и неавторизованная попытка превысить планируемый уровень качества, уложиться в меньшие сроки и многое другое.  Разумеется, экстра может принести и пользу, но нужно ли рисковать получением запланированного результата проекта ради чего-то дополнительного? Думаю, не стоит.

Ситуация вторая.

Ключевые пользователи, команда технической поддержки и успешное внедрение

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

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

В одной компании (как всегда, это была компания “Рога и Копыта”) открыли крупную и амбициозную программу. Программа подразумевала открытие нового направления бизнеса, под который необходимо было, в том числе, приобрести и внедрить новую ИТ систему. Проект по внедрению системы благополучно инициировали, наняли консультантов, провели тендер, выбрали систему и приступили к внедрению. Разумеется, внедрить крупную систему без доработок  невозможно. Поэтому, был проведен этап анализа разрывов (GAP analysis) между функциональностью системы и требованиями бизнеса. На каждый найденный разрыв была написана техническая спецификация, а на настройки самой системы – техническое задание. С момента написания технического  задания на проекте активно использовалась группа сотрудников, выступавших экспертами в своих областях. Эти эксперты планировались как ключевые пользователи системы. Именно они должны были обучиться работе в системе и в будущем, составить некий центр экспертизы компании по ИТ системе. Так оно и получилось. Момент обучения работе в системе предшествовал утверждению технических спецификаций и технического задания, поэтому у группы сформировалось понимание работы системы до того, как  она была доработана и запущена.

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

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

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