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

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

Мероприятия

Академия передовых практик внедрения и поддержки SAP (2013-2014) Дата проведения: 10-11 октября 2013 г. Все мероприятия

Слагаемые успешной трансформации ИТ: мотор для машины бизнеса

Для скачивания материала, необходимо войти на сайт или зарегистрироваться.

Сегодня мы с вами обсудим сложные и увлекательные взаимоотношения между бизнесом и IT. Для их иллюстрации я выбрал несколько картинок, и начну вот с этой – на ней изображены улитки и подпись: «Бизнес зависит от IT».

Значит ли это, что бизнес должен работать так же медленно, как движутся улитки? Увидев состав участников нашей сегодняшней встречи, я понял, что картинка должна быть другой: не про улиток, а про ракеты. Бизнес – ракета, но IT - ракетоноситель.

Ракета летит быстро, но после того, как ракетоноситель выведет ее на орбиту – 10 минут определяют судьбу полета, при этом время подготовки ракетоносителя для его миссии очень длительное.

Бизнесу и IT необходимо видение совместной работы – и на ближайшую, и на отдаленную перспективу. Про это – моя следующая картинка.

Вот это – очень правдивая иллюстрация того, как видят один и тот же океан, один и тот же бизнес 2 разных человека – один из бизнес-подразделения, а второй – из IT. Когда я увидел эту картинку, у меня возникли вопросы: а мы с бизнесом и IT в одном направлении смотрим, мы одно и то же видим? Даже если стоим рядом, и вроде бы перед нами один и тот же пейзаж.

Исследование MIT Sloan про IT в бизнесе показывает, что компаниям для проведения трансформации необходима эффективная IT-стратегия. ПО результатам опроса почти 80% опрошенных менеджеров, которые занимаются IT-трансформацией проекта, хотят как можно быстрее получить результаты. Однако они отмечают, что их организации слишком медленно получают эти результаты, трансформация идет медленнее желаемого. Почему медленно? Потому что нужны люди, которые будут постоянно оказывать поддержку этой трансформации, и главное, чтобы эти люди были на верхнем руководящем уровне в организации – президенты, вице-президенты.

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

Я могу порекомендовать книгу Чарли Филда «Мертвая зона» («Blind spot»), , про IT-трансформацию бизнеса. Чарли Филд был IT-директором во многих компаниях, и в этой книге он перечисляет основные вопросы, которые вы должны задать себе.

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

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

Если ответ на первый вопрос понятен, из него логически вытекает второй вопрос: «Что? Что мы должны сделать?».
Следующий вопрос – «Как? Как это сделать?».
И, разобравшись с этим вопросом, переходим к не менее интересному: «Кто? Кто это сделает?». Чарли Филд в своей книге считает, что самый сложный вопрос – это, конечно, первый, «зачем?».

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

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

Приведу пример - французская компания в 2004 году начала программу транформации, которую они назвали «1». Сначала они называли ее «Мост», потому что хотели строить мосты между головной компанией и несколькими другими компаниями, приобретенными в последнее время. На эту программу компания выделила огромные инвестиции. Но через пять лет они поняли, что уровень выполнения цели, объединения компаний, находится примерно на 10%, причем эти 10% сделаны на пути объединения с самыми маленькими из приобретенных компаний – до крупного бизнеса еще даже не дошли. К тому же за 5 лет все программные средства (а у них, между прочим, было внедрено решение SAP) уже устарели, и потребовались новые инвестиции – в модернизациюд. Другой пример – компания «ADS», которую мы сейчас знаем под именем «Airbus». Аналогичная история: огромные инвестиции, и минимальный результат.
Такие программы могут идти по инициативе бизнеса, а могут быть инициативой IT. Одной из инициатив на пути оптимизации IT может стать предложение передать эту функцию на аутсорсинг, в целях сокращения расходов. Причины могут быть разные: устаревание имеющихся систем, необходимость протестировать новые подходы, желание перейти в облако и так далее.
В качестве примера приведу еще компанию IBM – есть целый сайт их программы транформации, IBM Blue Harmony, где можно изучить, как меняется IBM. Очень интересный пример того, как IT-организация способствует трансформации компании. Причем далеко не все моменты там позитивны, некоторые могут выглядеть даже пугающе. Участник проекта говорят, что как только вы запускаете IT-трансформацию – ожидайте проблем. Все равно как если бы вы ехали на работу или с работы и вдруг увидели бы знак «дорожные работы» там, где ничто их не предвещало.

У каждого руководителя компании есть свои интересы и предпочтения. Было бы идеально, если бы СЕО интересовался IT, а CIO – бизнес-функциями. Если нет этого взаимного интереса – нет поддержки, и проекты просто обречены на провал.

Как мы можем повлиять на СЕО и CIO? Очень важно говорить с собеседником на одном языке, а для этого нужно этого собеседника понять и выявить, в чем его отличие. Невозможно общаться одинаково с администратором баз данных и с генеральным директором или ключевым акционером. Помните об этом. Большинство людей просто не понимают, о чем вы говорите. Мне кажется, очень интересно понять, как правильно выбрать слова, так, чтобы люди вас поддержали и поняли.

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

Проблема нашего времени – в том, что мало кто хочет вникать в детали, изучать проблему глубоко. Если бы это было не так, все мы давно бы уже научились разрабатывать решения SAP, освоили ABAP буквально за пару дней. Да-да, вы все могли бы стать разработчиками – может быть, не самыми лучшими, но азы бы освоили. Нежелание вникнуть и разобраться я считаю одной из причин того, что в России такое количество самописного кода, клиентских разработок и дополнений функционала решений SAP. Понятно, почему так происходит, – потому что есть люди, которые говорят: «Мы можем запрограммировать, написать, разработать то, чего вам не хватает». И могут при этом заработать на разработках внутри SAP.

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

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

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

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

Бизнес должен четко формулировать свои потребности, когда ставит задачи перед IT.

Приведу пример: крупная металлургическая компания, с огромной собственной командой программистов и весьма компетентным директором по IT. У них огромный объем собственной разработки, но выясняется, что только 50% того, что они делают, по факту используется. Как это произошло? Была поставлена задача, программисты сказали «можем», сделали больше, чем нужно было, передали в производство, – и оказалось, что этими разработками никто не пользуется. Но деньги-то потрачены, ресурсы потрачены.

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

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

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

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

Вопрос: как обеспечить себе поддержку бизнеса? Ведь, в конечном итоге, бизнес оплачивает вашу работу. Как сделать так, чтобы они были заинтересованы в результатах и вас поддержали? Допустим, у вас есть инновационная идея – как изменить компанию к лучшему. Нужно найти кого-то, кто поможет вам спланировать эти изменения - нужен архитектор. Вы с архитектором создадите план – и понадобится кто-то, кто будет его воплощать. Все это напоминает строительство дома. Но когда он построен, ничего не заканчивается, а наоборот – только начинается. Нужно переезжать в новый дом и в нем жить. Применительно к IT-системам это называется «run», запуск, продуктивная эксплуатация.

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

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

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

Если все это переводить на язык IT-проектов, бизнес будет постоянно приходить к вам с какими-то запросами, и вы должны «держать удар». В каких-то случаях вы будете архитектором, в других вы будете строителем, но в конечном итоге вам придется и эксплуатировать тоже все, что бизнес насочинял. Бизнес может обожать вас и будет с удовольствием работать вместе с вами на проекте, если они будут видеть для себя пользу от этого проекта, но сохранить этот интерес со стороны бизнеса, эту мотивацию в течение всего проекта очень сложно.

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

Со временем стратегии компании меняются, расходы начинают расти. Если проект слишком затягивается, люди теряют интерес. Со временем все течет, все изменяется, и более того, все исчезает. Это философский вопрос, имеющий прямое отношение к IT-проектам.

Поэтому, чем бы вы ни занимались, ни в коем случае не составляйте планы на годы вперед. Смотрите в будущее, но задайте себе вопрос: вы сами сколько готовы были бы ждать, скажем, новую машину? Или вы пришли в «Эльдорадо» купить новый телевизор - вы же не хотите его заказывать и ждать доставку? Потому что, если вам захотелось поменять телевизор, вы пришли в магазин, купили его и увезли с собой. А если вам в магазине говорят «время ожидания - три недели», я говорю: «Нет, hasta la vista», иду в соседний магазин «М.Видео» и забираю там телевизор с полки.

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

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

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

Успешный IT-проект, с моей точки зрения – такой, который реализован в формате, позволяющем на этапе эксплуатации делать все правильно и эффективно. Более того, если так получится у вас с первым проектом, если вообще вам нравится проектный бизнес, бизнесу это понравится и вам позволят делать новые и новые проекты в будущем. Приведу пример из авиации. Самолет Airbus, «А380», был испытан как опытный образец в 2005 году. В тот момент это был самый большой пассажирский самолет. И после успешных испытаний выяснилось, что перенести процесс создания этого опытного образца в производство нельзя без серьезных изменений. Три года ушло на то, чтобы настроить сборку этого самолета в рамках серийного производства. Вы запустили систему в продуктив, выпили шампанского – и начинается рутина, начинается нормальная работа, и это самое сложное. Успешный проект дает результат, который потом можно успешно эксплуатировать. А если его можно успешно эксплуатировать, значит, вам разрешит бизнес запускать другие проекты и заплатит за них.

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

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

И наконец – зачем существуют компании? Ради бизнеса, а не ради IT и не ради вас. Поэтому, если вы вовлечены в проекты, даже если это проект по IT-трансформации, помните – вы это делаете ради бизнеса. Я думаю, что вы будете успешными, если в своих проектах вы будете делать все быстро, будете давать результат как можно быстрее. В вашей стране некоторые организации, с моей точки зрения, абсолютно не амбициозны в том, что касается IT-внедрений. Вы не торопитесь никуда. Вы тратите слишком много времени.
Одна химическая компания потратила год на то, чтобы составить проект проекта, собрать требования бизнеса. Теперь они приступают к реализации. На реализацию они отвели 15 месяцев – на то, чтобы все описанное внедрить на двух своих заводах. Мне кажется, это абсолютно не амбициозно и похоже на ту французскую компанию, о которой я говорил: 5 лет на трансформацию бизнеса, 10% результата, 2 миллиарда евро. Так и здесь: из 15 заводов хотят автоматизировать 2 и потратить на это 15 месяцев. Представьте себе, сколько времени потребуется на то, чтобы потом распространить данный продукт на оставшиеся 13 заводов? И представьте себе, сколько еще изменений будет, пока они будут внедрять на 2 заводах, а потом еще на 13? Может быть, это классическая проблема больших компаний, что они никуда не торопятся, я не знаю.
Есть и другой пример: металлургическая компания на Украине, у которой от проекта до «большого взрыва» уходят те же самые 15 месяцев, а план у них был 9 месяцев, если уж совсем честно говорить. Сейчас они в октябре перешли на этап «go life». Они суперамбициозные - и, опять же, это крайности. Наверное, нужно искать золотую середину.
Представьте себе, сколько изменений придется сделать в проекте, если он будет идти год, два года. Те люди, которые запустили этот проект в самом начале, они еще будут работать в компании, в принципе? Вы лучше знаете свою компанию и свою страну, чем я. Но шанс того, что этих людей не станет в компании, достаточно велик, и это могут быть руководители - CIO, CFO. Иногда мне кажется, что это вечеринка какая-то, когда люди переходят из одной компании в другую так же, как некоторые гуляки шарахаются по всем пабам в течение одной ночи.

Если скорость – одна из ваших задач, пытайтесь использовать по максимуму тот функционал, который у вас уже есть, который вы уже купили. В Германии есть такая тенденция: при покупке новой машины вы можете собрать в интернете желаемую конфигурацию: пульт управления, кожаные кресла, и еще что-то. Потом вам показывают цену, и вы с этой информацией идете в дилерский центр и начинаете добиваться скидок за очень большую комплектацию, потом этот завод начинает вам эту машину собирать… Но как только вы забрали машину из дилерского центра, – она сразу теряет в цене 20%. 100 тысяч евро заплатили в дилерском центре, отъехали на 20 метров, пытаетесь продать – минус 20% к цене. Если я хочу, чтобы моя машина была особенной, уникальной, и если есть человек, который это сделает, – прекрасно: он заработает дополнительные деньги, а вы получите машину с зелеными кожаными сиденьями. Как только вы пошли таким путем, вы испортили свою машину. Вы заплатили 120 тысяч, но человек на следующем углу не купит у вас ее даже за 80 тысяч. Он купит ее, может быть, за 70, потому что никому, кроме вас, эта уникальность не нужна.
Как только вы собираетесь сделать ваш продукт особенным, очень специальным, очень уникальным, помните: на этапе эксплуатации его стоимость, его цена, его ценность может быть ниже.
И последнее, о чем я хотел сказать: бизнес и IT говорят на разных языках. Если мы не понимаем, что говорит наш собеседник, давайте ему об этом сообщим. Говорите на языке, понятным вашему собеседнику, помните, что люди имеют свою терминологию и говорят все на своих языках. Ставьте себя на их место, относитесь с симпатией к своим собеседникам. Если вы не заинтересуете собеседника, вы не сможете добиться успеха.


Об авторе:

АНДРЕАС БРАЙТЮК
SAP AG
Старший архитектор решений

В компании SAP с 1988 года. 25 лет успешной работы в области бизнес-процессов, технологий, продуктов SAP. Работая в офисе президента SAP Global Services, Андреас получил глубокий опыт в области внедрения, функционирования, управления жизненным циклом решений SAP. Андреас активно участвовал в разработке планов сотрудничества с ключевыми партнерами в СНГ: ОАО Газпром, РЖД, Аэрофлот и другие.