Аллергия на внедрение:
12 часто задаваемых вопросов
о том, почему пользователи отвергают новые продукты

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

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

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

В 1995 году внедрение ERP-системы провалилось в FoxMeyer Drugs, американском поставщике лекарственных препаратов с оборотом в 5 млрд долларов. Внедрение SAP R/3 проводилось методом «сверху вниз», без вовлечения конечных пользователей, что сначала вылилось в массовый саботаж работы компании рядовыми сотрудниками из-за опасения быть замененными инфосистемой, а в конечном итоге привело к банкротству компании в 1996 году. Владельцы компании пытались привлечь к ответственности как собственно разработчика — компанию SAP, так и внедренца — Andresen Consulting (теперь — Accenture), требуя возмещения убытков в 500 млн долларов с каждого.

Подробнее этот кейс рассматривается в учебнике Information Technology for Management: Advancing Sustainable, Profitable Business Growth (Efraim Turban, Linda Volonino, Gregory R. Wood. 10th Edition International Student Version. Wiley, 2015) и в статье The FoxMeyer Drugs' Bankruptcy: Was it a Failure of ERP? (Judy Scott, 1999).

Другой похожий случай произошел в Hershey Foods Corporation в 1999 году. Кондитерский конгломерат тогда внедрял сразу три IT-продукта. Однако недостаточное обучение сотрудников в использовании этого ПО обернулось медленным исполнением заказов: были сорваны сроки поставки товаров на общую сумму более 100 млн долларов. Биржа отреагировала на это снижением стоимости акций компании на 8%, а IT-директору пришлось уйти в отставку. Кстати сказать, новый CIO, Джордж Дэвис, успешно завершил внедрение благодаря тому, что одним из первых своих решений пересмотрел и существенно расширил программу обучения сотрудников.

Подробности этого внедрения описаны в кейсе ERP Implementation Failure at Hershey Foods Corporation (Indu Perepu, Vivek Gupta, lCFAl center for Management Research, 2008).

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

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

Искать таких людей лучше всего через профессиональные сообщества в LinkedIn или Google+. Но беседовать удобнее, конечно же, в офлайне, в неформальной обстановке — в кафе или за пивом. Если вы стесняетесь беспокоить незнакомых людей в соцсетях, посещайте тематические конференции: там в кулуарах или на афтерпати тема «Кто виноват и что делать?» весьма популярна.

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

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

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

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

Задача внедренцев — вести с бизнесом диалог, спрашивать, предлагать, советовать, обсуждать. Каким языком будет вестись этот диалог — языком цифр, русским матерным или красивыми картинками, — выбрать вам, вы же знаете своего клиента.

Не отличается.

Конечный пользователь обычно мало знает о происхождении продукта и не интересуется, кто его разработчик. Слова «вендор», «аутсорс», «коробочный продукт» для пользователей — белый шум. Конечно, иногда пользователь узнаёт знакомые имена в названии продукта, например SAP или Microsoft, но нет никаких подтверждений, чтобы имя влияло на реакцию пользователей. Успешность внедрения определяется подходом к пользователю, его вовлечению в процесс выбора решения, сбора требований, пилотной эксплуатации, но никак не именем или происхождением продукта.

Если сфокусироваться на «человеческих факторах», то выделю следующие пять.

Подчеркну — это не «список самопроверки», а список задач, которые должны быть учтены и проработаны еще на этапе планирования.

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

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

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

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

Проблемы с внедрениями были во все времена, и в эпоху DOS тоже. И требования к образованию не ослабевали ни сейчас, ни тогда. Это сегодня почти 100% офисных работников обладают компьютерной грамотностью хотя бы на каком-то уровне, поэтому освоение новой рабочей среды занимает у них меньше времени — уже не надо объяснять, что такое клавиатура, мышь, как включать компьютер и работать на нем так, чтобы избежать потери данных. Многих понятий той эпохи сейчас уже нет: практически невозможно столкнуться с отсутствием свободного места на диске, с необходимостью обмениваться данными на физическом носителе.

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

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

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