Многие проекты по внедрению комплексных автоматизированных информационных систем осложняются сопротивлением не только рядовых сотрудников, но и менеджеров среднего звена, и даже руководителей высшего ранга. Каковы причины возникновения этого «движения сопротивления», какие меры необходимо принять для профилактики или исправления ситуации? Своим опытом в области реализации ИТ-проектов делятся: Юрий Грозин, вице-президент «Сибинтека», Игорь Рудый, директор отдела руководителей проектов TopS BI, Андрей Крылович, вице-президент, директор департамента консалтинга TopS BI, Илья Прокимнов, директор по консалтингу Columbus IT Russia.
–Для того чтобы беседовать о работе с пользователями в ходе проекта, необходимо, прежде всего, определить: о ком мы говорим? Пользовательская среда неоднородна. Какие категории пользователей можно выделить?
Ю. Грозин: Я бы классифицировал пользователей следующим образом. Первая категория — бизнес-лидеры, заинтересованные в результатах внедрения информационной системы. Они являются движущей силой проекта со стороны бизнеса. Вторая категория — менеджеры среднего звена, которые имеют средний уровень готовности к проекту. Они осознают необходимость внедрения информационной системы, но не очень хорошо представляют те преимущества, которые они от нее получат, и те трудности, с которыми им предстоит столкнуться при внедрении. И, наконец, третья категория — бизнес-исполнители, которые менее всего радуются внедрению новых систем. На них, как правило, ложится основной груз работ по вводу первичных данных в систему, их пугает возможное изменение каждодневной деятельности.
А. Крылович: Пользователями могут являться многие сотрудники компании, но они, естественно, имеют различный статус. Как правило, чем выше статус человека, тем больше его влияние на проект.
Изначально в проект не вовлекаются все сотрудники. Одним из требований при заключении контракта является выделение ресурсов, причем описывается доля времени сотрудников, которая будет отдана проекту, и их статус. Осуществляется поименное согласование людей, которые вовлекаются в проектную группу. Люди, вовлеченные в проект, делятся на две категории команда проекта — сотрудники, вовлеченные в проект почти на полный рабочий день, и эксперты, которые не принимают участия в проекте на постоянной основе, но имеют право влиять на проектные решения. Постоянные участники проектной команды выполняют разработку и подготовку вариантов проектных решений, а эксперты участвуют в рассмотрении вариантов и окончательном утверждении проектного решения.
— В чем выражается готовность к проекту каждой из категорий пользователей? Чего они опасаются и что ожидают от внедрения системы?
И. Прокимнов: От чего зависит успех проекта? Во-первых, надо правильно поставить цели и сформулировать задачи. От того, насколько сильно желание руководства получить результат, зависит, в конечном итоге, этот результат. Важен правильный подбор и организация проектной команды, готовность всех участников работать в этой команде.
Готовность заказчика — это состояние, когда все участники проекта, начиная с его спонсора и заканчивая конечными пользователями, понимают и разделяют цели проекта. Это, вероятно, главное условие готовности заказчика к внедрению системы. Если оно выполняется, то все остальные проблемы носят организационный характер, их решить относительно просто. Если все сотрудники, так или иначе вовлеченные в проект, хорошо понимают, зачем это надо компании в целом и им лично, то проект с большой долей вероятности будет успешен. Для того чтобы такое понимание возникло, нужна очень серьезная работа. К сожалению, ее невозможно формализовать. Не существует готовых методик по осознанию целей проекта. Понятно, что надо их донести до сотрудников, правильно каскадировать, поскольку цели акционеров отличаются от целей генерального директора, а его цели не совпадают с целями ключевых специалистов. Поэтому важно правильно выстроить дерево целей, чтобы можно было получить ответ на любой вопрос относительно целей каждого конкретного человека в проекте. Если эта работа проведена, люди разделяют цели проекта, то можно считать, что степень готовности компании к проекту очень высока. Эта работа должна быть выполнена в самой компании, ее сложно делегировать сторонним специалистам, поскольку необходимо знать специфику компании — и бизнеса, и стиля руководства, и психологического климата.
А. Крылович: Рассмотрим треугольник «сроки — цена — качество». Стороны этого треугольника должны быть соразмерны. Нельзя рассматривать качество (а под качеством заказчик нередко подразумевает и количественные характеристики) в отрыве от денежных и временных ресурсов. Суперкачество быстро и дешево — это не из области управления проектами, а из области фантастики. Надо четко поставить цель проекта, эту цель разбить на задачи, описать эти задачи через бизнес-процессы, из полученного перечня выделить ключевые процессы. Чем лучше проект специфицирован, определены рамки и зоны ответственности, тем меньше неоправданных ожиданий. Поэтому, когда мы читаем в тендерном задании: «Цель проекта: внедрение ERP-системы», мы понимаем, что сталкиваемся с неуправляемыми ожиданиями. Люди должны понимать, что они хотят получить от системы.
Ю. Грозин: Когда начинается обсуждение необходимости или возможности автоматизации тех или иных бизнес-процессов, как правило, все руководители высшего звена, руководители финансовых служб ожидают сокращения персонала, вовлеченного в бизнес-процессы, которые автоматизируются. И когда они слышат, что в результате внедрения информационной системы, возможно, персонал не только не сократится, но и появятся новые роли, связанные, например, с вводом первичной информации в систему, они приходят в недоумение: зачем нужна такая система? Приходится долго доводить до сознания руководителей, что информатизация, или автоматизация бизнес-процессов, в первую очередь связана с тем, чтобы сделать информационные потоки прозрачными, контролируемыми и достоверными. Затраты на увеличение штата впоследствии окупаются той дополнительной аналитической информацией, которая поможет правильно спланировать объемы производства или определить регион продвижения продаж. А это вызывает к жизни появление новых ролей и должностей. Но было бы неправильно утверждать, что это явление обязательное и повсеместное. Очень часто внедрение системы позволяет не просто сократить штат некоторых подразделений, а даже ликвидировать некоторые службы. Теперь те же функции становятся полностью автоматизированными, выполняются компьютером гораздо оперативнее и с большей степенью надежности. Важно подчеркнуть, что повышается надежность исполнения процесса по сравнению с ручным трудом. Человеческий фактор — это всегда фактор риска.
— Какие группы пользователей наиболее сознательны и лояльны по отношению к системе, а кто, скорее всего, станет потенциальным противником нововведений?
Ю. Грозин: Если говорить о комплексной автоматизации, то сторонниками системы и ключевыми игроками команды проекта становятся, в первую очередь, финансисты, потому что они заинтересованы в тех оперативных и объективных данных, которые смогут из нее получить. Мой опыт показывает, что даже автоматизация бизнес-процессов, напрямую не затрагивающих финансовые службы, в итоге приводит к тому, что финансисты и экономисты находят те показатели, те ключевые моменты, которые позволяют им повысить эффективность бизнеса путем получения дополнительной аналитической информации, путем дополнительных контрольных функций.
И. Прокимнов: Да, финансисты часто бывают сторонниками внедрения системы, поскольку им теперь не приходится собирать данные из нескольких систем, процесс формирования управленческой финансовой аналитики значительно упрощается. Кроме того, наиболее сознательны и выражают наибольшую заинтересованность в системе закупщики. Для них внедрение системы не влечет негативных изменений в работе, напротив, они видят для себя определенную пользу, особенно если автоматизируется процесс планирования. Аналогично реагирует и служба управления запасами, особенно те, кто занимается перемещением запасов между филиалами.
Наименее позитивно воспринимает проект, как правило, отдел продаж. Коммерсанты — это люди, чья деятельность наименее формализована. Они привыкли работать «вольным стилем», оформлять заказы, если потребуется, задним числом, вносить исправления в документы. Это они объясняют клиентоориентированностью. Поэтому, когда от них начинают требовать работы по строгим правилам, они начинают отстаивать привычный «творческий» подход к делу. Противниками системы часто становятся и сотрудники складов. И, конечно, в силу понятных причин — бухгалтерия.
— От чего зависит степень лояльности людей к проекту?
И. Рудый: Когда люди сталкиваются с системами, в которых стандартная поддержка бизнес-процессов отличается от той, к которой они привыкли, возникает естественное недовольство. Поэтому отношение к проекту зависит во многом от личностных качеств человека. Если он по натуре позитивист, то он может принять то решение, которое заложено в системе, либо найти некий компромисс с системой при посредничестве специалистов по внедрению. Если человек категоричен в своих суждениях и уверен, что его точка зрения — единственно верная, он будет уводить проект в сторону дополнительных разработок. Мы стараемся заранее лимитировать дополнительные разработки, оговаривая их объем в контракте, все работы сверх лимита выполняются за отдельную плату. Это делается для того, чтобы проект не стал неуправляемым. Таким образом, мы пытаемся указать высшему руководству, что недовольство сотрудников может значительно увеличить бюджет и сроки проекта. Мы не стремимся заставить людей работать так, как им не нравится, нет — этими мерами мы пытаемся обратить внимание людей на стандартный функционал системы: вполне возможно, их негативное отношение обусловлено не недостатками системы, а ее непривычностью. Кроме того, дополнительные разработки очень недешевы, совокупная стоимость доработок может достигать нескольких сотен тысяч долларов.
А. Крылович: Можно построить график лояльности (ожиданий и удовлетворенности) людей к проекту. Сначала, как правило, ожидания очень высоки: система представляется едва ли не идеальной, способной решить все накопившиеся проблемы. Но, по мере накопления знаний о системе, люди обнаруживают, что какие-то функции в ней не реализованы вовсе, а что-то реализовано не так или не совсем так, как они себе представляли. И кривая их ожиданий и удовлетворенности начинает идти вниз. В случае неоправданных ожиданий «черный список» расхождений желаемого и действительного растет, и примерно через 4–6 месяцев наступает момент, когда и у руководства, и у ключевых специалистов возникает желание разорвать контракт. Если эмоции одолевают рассудок, проект действительно может прекратиться. Если людям хватает здравого смысла управлять ситуацией и оценить не только минусы, но и плюсы, проект продолжается. Как только люди видят какие-то реальные результаты внедрения системы, кривая ожиданий и удовлетворенности начинает идти вверх и со временем выходит на плато.
Такое развитие событий — процесс совершенно объективный. Заказчик обязательно должен знать о предстоящей «точке усталости» и приложить усилия к тому, чтобы ключевые специалисты, влияющие на принятие решения, брали в расчет не только не оправдавшиеся надежды, но и очевидные преимущества системы.
И. Прокимнов: Хочу к этим словам добавить лишь, что если комплекс ожиданий создается силами внутренней команды, то разница между желаемым и действительным будет гораздо меньше.
Ю. Грозин: Я не соглашусь, что резкое снижение ожиданий происходит всегда. Бывает, что система, напротив, имеет больше возможностей, чем от нее ожидали в начале проекта.
Справедливости ради надо отметить, что ожидания клиента не возникают сами, они во многом формируются продавцами. Если на предпродажном этапе вам наобещают «золотые горы», а в процессе внедрения ключевые пользователи напишут внушительный список претензий к системе, разочарование наступит неизбежно.
И. Прокимнов: Совершенно верно, во многом на ожидания влияет организация проекта. Если проект изначально организован путем выбора поставщиков, приобретения системы и затем ее внедрения с помощью этих поставщиков, то рассуждения коллег о неизбежности «точки провала» верны. На начальном этапе выбора поставщики прилагают активные усилия к тому, чтобы повышать ожидания клиента. Предпродажная подготовка — инструмент конкурентной борьбы, поэтому ожидания заказчика несколько искусственно раздуваются, равно как и снижаются расценки на услуги. Насколько ожидания раздуются и насколько будет снижен бюджет проекта, во многом зависит от участников тендера и уровня профессионализма специалистов заказчика. Профессионалы не станут принимать на веру несбыточные обещания и смогут с большой степенью точности отделить реальные посулы от фантастических. Непрофессионалы будут ожидать чуда.
А дальше начинается проект. Реализовать его приходят не те люди, которые продавали систему, а консультанты, которые, напротив, начинают прилагать усилия к тому, чтобы вернуть заказчика «на землю». Наступает период разочарований: оказывается, что обещания не то чтобы совсем не соответствуют действительности, но не отвечают ей в полной мере. Кривая ожиданий резко идет вниз. Разница между желаемым и действительным зависит от того, насколько заказчик позволил себя увлечь в процессе выбора системы.
— Вероятно, на величину этой разницы напрямую влияет наличие у заказчика человека, который по сути является CIO, как бы ни называлась его должность — человека, который является связующим звеном между бизнесом и ИТ.
И. Прокимнов: Я бы уточнил: необходимо, чтобы кто-то выполнял эту функцию. Будет ли это генеральный директор, финансовый директор или специально выделенный специалист — не столь важно. Кому делегированы такие функции, зависит от масштаба организации, степени загруженности первых лиц, их желания вникать в проблемы ИТ. Я, например, знаю несколько генеральных директоров, которые сами имеют техническое образование, постоянно интересуются сферой информационных технологий и с большим энтузиазмом подходят к выбору и внедрению автоматизированных информационных систем. Поэтому функции CIO может выполнять и генеральный директор. Хотя в большинстве случаев генеральные директора не в состоянии заниматься ИТ, и эти функции передаются отдельному специалисту.
В любом случае, эта функция нужна, экспертиза по решению задач бизнеса с использованием ИТ должна быть. Если в компании нет носителя соответствующих компетенций, то эту задачу решают специалисты поставщика по предпродажной подготовке. И тут, как мы уже рассмотрели, возникает проблема завышенных ожиданий.
А. Крылович: По поводу CIO и ИТ-специалистов рискну высказать парадоксальное, на первый взгляд, утверждение: чем больше ИТ-специалисты участвуют в проекте внедрения информационной системы — тем хуже для проекта. Проект внедрения системы информационной поддержки бизнеса, по сути, не является ИТ-проектом. Данный проект должен рассматриваться и управляться, исходя из целей и задач бизнеса. Конечно, есть компании, где ИТ-службу возглавляет человек, который по своей сути является CIO, как бы ни именовалась его должность. Но важно отметить, что на этого человека не следует возлагать полную ответственность за разработку ИТ-стратегии. ИТ-стратегия является частью бизнес-стратегии, и CIO принимает активное, но не определяющее участие. Определяющее значение имеют особенности развития бизнеса. Разработка ИТ-стратегии, как правило, поручается сторонним консалтинговым компаниям, которые, обладая знаниями и опытом, увязывают направления развития бизнеса с ИТ-поддержкой. Таким образом, компания получает перечень ИТ-проектов, которые должны быть выполнены. Эти проекты можно условно разделить на две категории. Первая категория — проекты, касающиеся создания и поддержки инфраструктуры обработки и передачи информации. Их реализация целиком находится в ведении ИТ-службы. А вот внедрение систем ERP, CRM, SCM, CPM ИТ-службе передавать нельзя. ERP-система поддерживает ключевые процессы управления финансами, логистикой, производством. Вопросы их поддержки не лежат в зоне компетенций ИТ-службы, это сфера бизнеса. Такими проектами должен управлять либо CEO, либо CFO, либо полномочный представитель генерального директора. CIO в данном проекте предоставляет необходимые ресурсы и готовит персонал к сопровождению системы.
Ю. Грозин: Действительно, как показывает практика, примерно половина проектов, которыми руководят ИТ-специалисты, оказываются неудачными. Когда руководство проектом осуществляет бизнес-специалист, процент успешных проектов гораздо выше. Причем чем выше статус и полномочия этого специалиста, тем больше шансов на успех внедрения. Бизнес-лидеры наиболее заинтересованы в успешности внедрения. Но, к сожалению, пока в среде бизнеса очень редко можно найти готового менеджера проектов, который может привести проект к успешному финалу. Здесь надо еще много работать и учить менеджеров среднего звена руководить проектами.
И. Прокимнов: Более того, было бы ошибкой считать, что ИТ-специалисты поголовно и всегда являются апологетами системы. Нередко бывает наоборот. Дело в том, что новая система зачастую приходит на смену «детищу» отдела ИТ — собственноручно написанной системе. «Айтишникам» начинает казаться, что их авторитет в компании стремительно падает. Если раньше они были совершенно уникальными и незаменимыми сотрудниками, то теперь они будут легко заменимыми и оттого гораздо менее ценными. Более того, они пока некомпетентны относительно новой системы, и им придется потрудиться над повышением своего профессионального уровня. Они начинают придирчиво изучать функционал и архитектуру системы, находя множество «недостатков» и «просчетов». Со стороны это выглядит несерьезно, но, увы, такие ситуации с завидным постоянством повторяются на многих проектах.
Но, конечно, так происходит не в ста процентах случаев, бывает и наоборот, когда отдел ИТ становится настоящей опорой команды внедрения, причем взаимопонимание достигается очень быстро, поскольку люди говорят «на одном языке».
— Отношение любых специалистов к проекту обусловлено двумя факторами: личностным и профессиональным. Личностный фактор определяет в целом отношение человека к переменам, к какой бы области жизни они ни относились.
Профессиональный фактор порождает два сценария: человек либо воспринимает внедряемую систему как инструмент повышения профессионального уровня, либо как соперника. Понятно, что в первом случае он будет всячески способствовать проекту, а во втором — бороться за сохранение своего статуса носителя неких уникальных компетенций. Мы поговорили об источниках негативного отношения к проекту ИТ-специалистов. А чем определяются ожидания и опасения бизнес-менеджеров? Насколько они оправданны, и как найти положительный выход из этой ситуации?
И. Рудый: Причины недовольства ключевых пользователей можно условно разделить на несколько категорий. Первая — непривычность новой системы. Человек привык к функциональным возможностям старой системы, не находит точного совпадения с соответствующими возможностями новой, и у него возникает ощущение, что «новая система ничего не может». Вторая: недовольство управлением проектом со стороны подрядчика. Третья причина — отсутствие видимых результатов: «деньги вложены, время идет, а отдача нулевая». Это особенно характерно для высшего руководства. Поэтому проект изначально должен строиться таким образом, чтобы можно было получить хоть какой-то результат: прототип системы, тестовые отчеты и т. д.
Особо стоит остановиться на одной из основных причин негативного отношения менеджеров — перекладывание забот по внедрению системы на плечи подрядчика. Большой ошибкой будет ожидать, что кто-то сделает за вас сложное и масштабное дело, при этом угадав ваши слабо осознанные и детально не описанные потребности.
Рассмотрим с этой точки зрения этапы проекта и поведение заказчика. На этапе обследования консультанты нередко вынуждены строить работу по принципу поиска грибов в лесу: что нашел, то твое. А что не нашел, то не попадет в описание бизнес-процессов, со всеми вытекающими последствиями для проекта. Специалисты заказчика пассивно наблюдают за сбором информации, считая это делом консультанта, и твердо отклоняют попытки вовлечь их в процесс — работы и без того хватает. Между тем, сбор информации — это зона совместной ответственности заказчиков и консультантов.
Следующий этап — разработка бизнес-процессов и решений. Очень часто решение разрабатывают консультанты, поскольку заказчик самоустраняется от процесса. В результате возникает психологическая проблема: заказчик ощущает себя не коллегой консультанта, а приемщиком работ. Но консультант — не золотая рыбка, адекватное решение может быть создано только ценой совместных усилий.
А. Крылович: Можно провести аналогию с вождением автомобиля. Никто, будучи в здравом уме, не станет учиться водить машину, посадив на место водителя инструктора и изредка наблюдая за его действиями. Но почему-то при внедрении информационной системы подобное происходит довольно часто. В результате, несмотря на потраченные средства, специалисты заказчика оказываются неспособны управляться с системой. Для того чтобы избежать такой ситуации, они должны «сесть за руль» — принять самое непосредственное участие в проекте. Только так люди могут научиться управлять предприятием с помощью системы.
Ю. Грозин: Отношение человека к предмету в большой степени определяется качеством предмета. Если информационная система позволит избавить людей от рутинной работы, они довольно быстро поймут, что новый инструмент облегчит им жизнь, позволит выполнять работу с лучшим качеством, и вопрос о лояльности будет решен. Начнется конструктивное сотрудничество с внедряющими, люди станут давать дельные советы по повышению эффективности своего труда.
Но не надо забывать, что люди сопротивляются внедрению системы не только из «высоких» профессиональных соображений. Есть категория сотрудников, которые пытаются, как говорили раньше, получать нетрудовой доход путем обмана и хищений. Эта прослойка очень тонкая, но она есть. Они будут активно противодействовать системе, ясно понимая или подозревая, что информационная система вскроет механизмы их злоупотреблений, причем постараются вербовать себе сторонников из числа сомневающихся сотрудников, намеренно извращая факты и показывая будущее в черном свете. Этих людей совершенно не надо убеждать и перевоспитывать — от них надо избавляться.
— Если ожидания от проекта ключевых специалистов — например финансового директора, специалистов планового отдела и т. п. — в основном позитивны, то ожидания рядовых сотрудников часто бывают негативными: грядут перемены с неясным, а потому пугающим результатом. Ну, если не пугающим, то настораживающим. Некоторые руководители проектов уверены: добиться лояльности конечных пользователей невозможно в принципе, их можно только заставить принять систему. Аргументация такова: как можно добиться лояльности от людей, которым с внедрением системы станет работать сложнее, непривычнее, дополнительной финансовой выгоды это усложнение не принесет, да еще часть рабочих мест будет сокращена?
И. Рудый: Неудовлетворенность заказчика — это всегда неудовлетворенные ожидания. Ожидания бывают оправданные и неоправданные. Об оправданных ожиданиях долго говорить не стоит: эти претензии совместно с подрядчиком анализируются и удовлетворяются. С неоправданными ожиданиями дело обстоит сложнее.
Недовольство конечных пользователей при внедрении масштабной системы неизбежно. Что ожидает человек, когда ему заменяют прежний станок на более совершенный? Облегчения ручного труда, реализации некоторых новых возможностей и снижения временных затрат на выполнение привычных операций. И практически всегда эти ожидания оправдываются. От информационной системы ожидают примерно того же. Но ERP-система никогда не внедряется с целью облегчить жизнь пользователей. Ее цель — обеспечить руководство и менеджмент полной, достоверной и оперативной информацией. А для получения более качественной и полной информации требуется, как правило, дополнительная аналитика. Сама по себе она не появится, данные для нее надо вводить в систему. Поэтому при внедрении системы трудоемкость процесса для конечных пользователей всегда возрастает.
Другая причина недовольства пользователей — универсальность комплексной системы. Специализированная система лучше отражает процесс, она будет интуитивно понятна людям. Универсальная система требует дополнительных усилий по ее освоению. И пользователям совершенно неясно: зачем было менять такую привычную удобную систему на эту, с их точки зрения, несовершенную? К сожалению, подавляющее большинство заказчиков не объясняют людям истинные цели внедрения системы. Вернее, объясняют уже после того, как недовольство начинает принимать угрожающие размеры. Очень желательно, чтобы такое объяснение имело характер упреждающего воздействия. С самого начала проекта компании необходимо проводить просвещающие мероприятия, чтобы у конечных пользователей на этапе запуска системы не было шока.
И. Прокимнов: «Предупрежден — значит, вооружен»: необходимо заранее выявить картину ожиданий и опасений рядовых сотрудников. Как правило, на практике применяется каскадный подход, когда менеджер собирает информацию у своих подчиненных. Когда собираются совещания проектных комитетов, на их заседания приходят менеджеры, которые представляют, чем живут их сотрудники, кто чем будет недоволен. В средних компаниях, как правило, таких специалистов немного, практически все у всех на виду, и даже финансовый директор обладает информацией по участкам — о тревогах и ожиданиях сотрудников. В крупных организациях эта проблема, конечно, сложнее, требуется применение специальных методик и процедур по сбору информации.
Я с некоторым скептицизмом отношусь к применению формализованных методик опроса пользователей для последующего анализа их ожиданий и тревог. Практика показывает, что способность людей к формализации и структуризации своих представлений и желаний достаточно низка, поэтому результат получается не соответствующим действительности. Пожелания и ожидания пользователей должны выражать сотрудники, облеченные некоторыми компетенциями и полномочиями. Они зачастую могут лучше сказать за пользователей, чем те действительно будут недовольны, а что примут с энтузиазмом.
А. Крылович: Конечно, нельзя допустить, чтобы для конечных пользователей увеличение объема работы стало единственным результатом внедрения системы. Должны проходить организационные изменения. Руководство вместе с консультантами проводит эти изменения. И так выявляются участки, где часть операций вообще может быть снята.
Но я бы не сказал, что нагрузка на конечных пользователей невероятно возрастает. Мифы о том, как, например, система осложнила жизнь несчастной пятидесятилетней кладовщицы, и она из последних сил ей сопротивляется, сильно преувеличены. Для всех конечных пользователей создаются ролевые схемы, они обучаются работе в системе, и у них, в конечном итоге, появляется всего несколько дополнительных функций. Нагрузка увеличивается у людей, занимающихся умственным трудом.
Ю. Грозин: К сожалению, это не всегда миф. Есть категория сотрудников, которые противятся внедрению системы в силу психологических или возрастных особенностей. Им в принципе сложно освоить что-то новое. С ними приходится расставаться, хотя они являются специалистами высокой квалификации и совершенно лояльны к компании. Это решение дается руководителю непросто, поскольку такие люди часто вызывают симпатию. Но дело страдать не должно.
А. Крылович: Важно донести до рядовых сотрудников, что с внедрением системы начинают меняться функции конечных пользователей. Они из людей, которые раньше просто вводили первичные документы, превращаются в аналитиков. Возникает смещение от ручного труда к умственному. Для пользователей это создает дополнительные возможности. Поэтому «жизнь после проекта» напрямую зависит от самого человека. Если он ничего не хочет от жизни, он будет просто выполнять ряд функций, а если он стремится узнавать новое и развиваться, то система может предоставить ему дополнительные возможности.
И. Прокимнов: Могу привести наглядный пример плохо проведенной «идейно-политической» работы в среде пользователей. В одном из наших проектов внедрялась система адресного хранения на складе. До внедрения системы кладовщики сами принимали решение о размещении товаров на складе, и признаком качества их работы являлось правильное и компактное размещение. Уровень их компетенции служил источником не только материального поощрения, но и профессиональной гордости. После внедрения кладовщики игнорировали схемы размещений, предлагаемые системой, и продолжали размещать товары по собственному усмотрению. В результате со временем накопилось огромное количество расхождений, при обнаружении которых система блокировала ячейки и предлагала провести инвентаризацию. Такая ситуация возникла из-за недопонимания людьми их новой роли: система не заменяла их, а избавляла от части работы, давая возможность выполнять заказы клиентов более быстро и качественно. Кладовщики же восприняли ее как конкурента.
— Отличается ли работа с пользователями, впервые принимающими участие в подобном проекте, от работы с теми, кто уже пережил неудачный проект?
И. Прокимнов: Пользователям, пережившим неудачный проект, надо помочь преодолеть негативное отношение. Они нуждаются в большем внимании, в объяснении, что в прошлом проекте было сделано неправильно, в том числе и ими самими. Им надо показать положительные отличия нынешнего проекта от прошлого и довольно быстро предоставить промежуточный результат, который им понравится. Например, какой-нибудь отчет или форму, которая облегчит выполнение повседневных обязанностей. Возможно, эти доработки не были предусмотрены изначально, но ради лояльности пользователей на них стоит пойти. Это улучшит отношение к команде внедрения.
С людьми, которые никогда не принимали участия в проектах, надо работать с точки зрения их ожиданий. Нередко их ожидания опираются на те, скажем прямо, странные представления, которые они получили из печати, и в результате они считают систему подобием некоего искусственного интеллекта. Надо аккуратно приводить их представления от фантастики к реальности.
Ю. Грозин: Конечно, «с чистого листа» внедрять систему гораздо комфортнее. Пользователи, пережившие неудачный проект, будут постоянно сверять текущий проект с тем негативным шаблоном, который у них сформировался в ходе предыдущего проекта. Человек по своей природе консерватор, все новое для него — стресс. И, если люди не мотивированы на результат, то надо будет прилагать постоянные дополнительные усилия, чтобы удержать их лояльность на приемлемом уровне.
— Вы затронули одну из основных тем сегодняшнего разговора — тему мотивации. Есть два вида мотивации: позитивная и негативная. Негативная — это жесткие административные меры, вплоть до увольнения. Позитивная мотивация может быть материальной и нематериальной. Какие способы мотивации (материальной и нематериальной) выбрать для каждой из категорий пользователей? Как правильно построить систему мотивации?
И. Прокимнов: Мы исходим из того, что генеральный директор не нуждается в мотивации, он уже изначально является если не инициатором, то сторонником проекта. Без его желания проект не начнется. Если проект все же стартовал на фоне скептицизма гендиректора, то эту проблему надо срочно решать: от этого человека зависит и бюджет проекта, и отношение к нему ключевых специалистов. Предложить какие-то готовые методики тут невозможно, надо действовать по ситуации.
Теперь о мотивации менеджеров. Если в компании действует система управления по целям, то проект надо обязательно включить в перечень задач менеджера на конкретный хронологический период, например на год. Мы неоднократно сталкивались с ситуацией, когда менеджеры вовлекаются в проект и даже выполняют какие-то проектные работы, но делают это совершенно формально. В приватных беседах они объясняют: реализация проекта не является их задачей, и руководство совершенно не интересуется, каким образом менеджер участвует в проекте. Зато с него строго спрашивают выполнение его основных обязанностей. Получается, что проект — обременительная нагрузка. Поэтому надо четко объяснять людям, что проектные задачи имеют ничуть не меньший приоритет, чем их основные обязанности. Возможно, список этих обязанностей на время проекта надо пересмотреть — например, запланировать меньший объем продаж, чтобы человек не пребывал в постоянном страхе, что он не успеет сделать два дела сразу. Если предусмотрена денежная мотивация, то человек должен ясно видеть, как количество и качество его усилий по проекту отражается на размере премии. Причем премию тоже можно разбить на части: размер одной будет зависеть, например, от сроков внедрения, другой — от качества работы. Тогда люди будут заинтересованы в качественном выполнении работ в запланированные сроки.
Ю. Грозин: Совершенно верно, бизнес-лидер должен понимать те преференции, которые может дать внедрение информационной системы или технологии для повышения эффективности бизнеса. Если у него нет четкого понимания, то с ним надо вести долгую и временами тяжелую разъяснительную работу. Если эту стадию не пройти, проект, какие бы инвестиции в него ни делались, скорее всего, обречен на провал.
В одной из организаций я, будучи руководителем направления ИТ, попытался предложить бизнесу создать информационную среду, которая позволила бы повысить прозрачность и эффективность бизнес-процессов. Проект стартовал, но в ходе реализации я не только не получил поддержки руководства, но и постоянно чувствовал сильное негативное отношение к проекту. Система была развернута, но ею никто не стал пользоваться. Руководитель бизнес-направления воспринял внедрение системы как знак недоверия к себе, поскольку теперь все процессы, подконтрольные этому руководителю, стали четко формализованы и прозрачны. Человек еще не созрел до понимания того, что система — не средство контроля за ним, а инструмент ведения бизнеса в его руках. Он не был готов к тому, чтобы начать использовать этот инструмент для повышения эффективности бизнеса.
Сейчас настало время весьма прагматичных бизнес-лидеров. Они хорошо умеют считать деньги. И если они не увидят, какой экономический эффект принесет им внедрение информационной системы, они на него не пойдут. Поэтому им можно только аргументированно доказать пользу от внедрения системы. Нужны постоянные диалоги, постоянное просвещение бизнес-лидеров.
А. Крылович: Очень важно не только поддерживать, но и демонстрировать коллективу заинтересованность руководства в результатах проекта. Тогда люди будут понимать, что их незаинтересованность в проекте чревата для них лично большими рисками. Это не значит, что первое лицо должно ежедневно участвовать в реализации проекта — доля участия зависит от размера компании, от стиля руководства, от структуры управления. Но прохладное отношение руководства охладит климат проекта в целом.
