Роланд Кристен

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

Во-первых, вовлечение не означает просто присутствие на встречах: этого недостаточно. Бизнес-подразделение должно действительно участвовать в проекте — эффективным образом, уделяя значительную часть времени для обеспечения окончательного успеха. Важно, чтобы все участники проекта, включая сотрудников бизнес-подразделений, понимали, что в проекте нет отдельной части, относящейся к бизнесу, и другой отдельной части, относящейся к ИТ. Проект — это сотрудничество. Люди должны работать над проектом вместе. Мы все в одной лодке, просто в этой игре у нас разные роли.

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

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

Управление изменениями: как помочь пользователям принять новое

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

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

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

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

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

Do You Speak SAP? (Как важно говорить на одном языке)

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

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

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

Еще одна возможность — организовать демонстрации систем для управления бизнес-процессами или других систем SAP. Можно, например, организовать демозоны либо мероприятия по примеру этого, которые позволяют не только понять системы и процессы, но и построить взаимоотношения с людьми, на опыт которых вы будете опираться позже. Можно посещать другие компании, создавать дискуссионные группы с людьми, которые уже долгое время используют подобные системы и обладают большим опытом. И если вы будете делиться своим опытом с другими компаниями, которые еще не имеют нужных знаний, то потом, возможно, эти компании смогут поделиться с вами своим опытом.

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

От идеи — к решению

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

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

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

Когда я говорю о проектах внедрения, я понимаю, что у вас также есть определенный опыт в этой сфере. Когда речь идет о выявлении узких мест и поиске путей их устранения, то естественной реакцией становится дополнительная разработка. Решения SAP могут все, разве что не могут приготовить вам кофе, поэтому чаще всего лучше потратить чуть больше времени на то, чтобы разобраться, найти альтернативное решение и обойтись без дополнительной разработки. Чаще всего разработка — это самый быстрый способ решить проблему, но не всегда он лучший. Поэтому, чтобы понять и согласовать объем проекта, важно проводить обсуждения с представителями бизнес-подразделений. Эти обсуждения могут проходить в формате семинара, но на практике это часто сводится к получасовым собраниям, участники которых просто говорят: «Все нормально, продолжаем внедрение». И это не самый эффективный способ построить лучшую систему. Правильнее проводить регулярные обсуждения с представителями бизнеса: начинать с того, что уже сделано, рассказать о логике проекта и принятых решений и предложить утвердить ее.

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

От 50 до 100 % времени в рамках проекта отводится на взаимодействие ИТ-подразделения и бизнес-подразделений. То есть степень вовлечения бизнеса довольно высока. На различных ролях в руководящем комитете, при подведении итогов проекта, в ходе тестирования, на других этапах я практически всегда сталкивался с этим на презентациях, при рассмотрении коммерческих предложений, в рамках подготовки статистики по проекту. Сотрудникам бизнес-подразделений требовалось выделять на проект от 50 до 70 % своего времени.

Конечно, легко согласовать цифры вовлеченности в проект на бумаге, но когда речь заходит о реальном выделении ресурсов, то оказывается, что у сотрудников бизнес-подразделений просто нет времени. Как можно требовать от них на 100 % выполнять свою основную работу и выделять еще 50 % времени на участие в проекте? Так не получится, люди не могут выкладываться на 150 %, а если и могут, то недолго. Необходимо найти другие варианты привлечения их к проекту. Есть разные способы освободить этих людей от части рутинных обязанностей, чтобы у них появилось больше времени на ИТ-проект. Если вам повезло и вы можете определять, чем должен заниматься тот или иной сотрудник в рамках проекта и какие изменения влияют на его работу, то вы можете донести эту информацию до других людей, которые также могут быть вовлечены в проект и на которых могут повлиять ваши решения. Но вам недостаточно просто сказать: «Больше не делайте это, мы это делаем по-другому». Ведь другие сотрудники компании не будут знать о том, что этот человек уже вовлечен в ИТ-проект, они будут обращаться к нему по обычным рабочим вопросам, как делали это последние пять лет, и в результате он погрязнет в повседневной рутине.

Создаем проектную команду

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

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

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

Как же строится вовлечение сотрудников бизнес-подразделений на разных этапах проекта? На рисунке указана структура решения SAP: мы начинаем с подготовки проекта, но и до этого, и позже — на стадии совершенствования после внедрения — привлекать сотрудников бизнес-подразделений просто необходимо на большинстве этапов.

Материалы для скачивания

Роланд Кристен, Бизнес-заказчик – друг или враг?006_CEP_pr_rus.pdf534.58 KB