Ещё по теме

Комментарии по теме

«Игровой ролик: SAP для Retail»
Александр Дублин:
Суть ролика: если хотите спать в рабочее время, унижать подчиненных, то с решением от SAP вам это будет удобно. Сценарий ролика - продолжения истории: top-lap.livejournal.com/502664.html

Мероприятия

Академия передовых практик внедрения и поддержки SAP (2012-2013) Все мероприятия

Роланд Кристен, Бизнес-заказчик – друг или враг?

Предыдущая Следующая

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендация

Проводите регулярные обсуждения с представителями бизнеса: опишите, что уже сделано, расскажите о логике проекта и принятых решениях и предложите утвердить ее.

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

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

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

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

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

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

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

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

Рекомендация

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

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

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

Рекомендация

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

Примеры и выводы

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

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

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

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

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

Сессия вопросов и ответов:

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

Ответ (Роланд Кристен): Спасибо за вопрос, он очень важный и имеет четкую практическую направленность. Что я могу сказать? Я думаю, что за проект не должен в полной мере отвечать ни представитель ИТ, ни бизнеса. Должно быть сотрудничество: оба подразделения должны работать вместе, и, как вы сказали, находить компромиссы. За последние два десятка лет, которые я работаю, использовалось несколько вариантов. Иногда проектную группу и весь проект возглавляли представители ИТ-подразделения. Они пытались гармонизировать систему, разбив внедрение системного ландшафта на этапы. Но это не работало, поскольку ИТ-подразделение предлагало продукт, который не принимали бизнес-пользователи, система им не нравилась.

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

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

Вопрос: Если я понял вас правильно, если по какой-либо причине вы не смогли прийти к единой точке зрения, то нужно остановиться и попытаться понять эту причину, а затем продолжать. Да? Я правильно понял?

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

Вывод

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

Об авторе

РОЛАНД КРИСТЕН
Bridge2sap4hcm GmbH
Консалтинг Менеджер

Роланд работает в экосистеме SAP с 1993 года. Как бывший директор по персоналу в Швейцарской компании, он имеет практические и глубокие знания по управлению персоналом. Благодаря многолетнему опыту работы с решениями SAP по управлению персоналом (НСМ) Роланд может рассказать о международных проектах в различных отраслях промышленности. Роланд прекрасный спикер и не раз организовывал сложные воркшопы с клиентами по управлению изменениями в организации, становясь немедленно доверенным лицом в компании, умеющему вникать в детали ситуации.
Роланд поделится своим опытом в том, как ИТ решения влияют на изменение процессов и структуры организации.