Я возглавляю подразделение SAP, которое отвечает за разработку локальных версий SAP для стран СНГ: от классических ERP до банковских решений, решений для управления транспортом и логистикой, облачных решений и так далее. В SAP я работаю 2 с половиной года, а до этого около 15 лет работал с «другой стороны баррикад»: был клиентом SAP, работал в крупной международной компании. У нас было 38 тысяч лицензий, в последние 3 года я отвечал за внедрение SAP во всей компании. По  моим подсчетам, я внедрял SAP в 72 странах, и где-то в половине из них даже удалось побывать.

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

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

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

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

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

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

Поэтому ответ на вопрос, нужна ли, собственно, разработка, или не нужна, очевиден. Конечно, нужна. Вопрос в том, чтобы найти баланс между стандартными возможностями и собственной разработкой.

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

Например, SAP HANA, которая позволяет сейчас делать такие вещи, которые раньше физически нельзя было сделать. Именно в этом заключается, на мой взгляд, основная задача внедрения SAP – как найти баланс. Он выглядит по-разному в разных странах: оптимально, когда соотношение – 80 на 20 процентов. 80 – стандарт, 20 – собственные разработки. А вот если бы у вас 50 процентов собственные разработки, или даже более, тогда что-то не то. Потому что в SAP, на самом деле, есть много возможностей, позволяющих обойтись без такого объема собственного кода. Но нужно понимать, как это соотношение посчитать. Естественно, я имел в виду соотношение не вообще всего, что есть в SAP, а той функциональности, которую вы используете. Считать можно по-разному. Можно по той функциональности, бизнес-функциям, которые есть. Можно по количеству строчек кода.

Что включать в собственные разработки?

Здесь я сделаю лирическое отступление. Когда я начал работать в SAP, две вещи меня поразили. До этого я общался либо с Вальдорфом, либо с офисом SAP в Цюрихе, поскольку головной офис компании, в которой я работал, был в Женеве. Когда я начал работать с российскими компаниями, то обнаружил, во-первых, как мало российские компании знают о том, что они купили за свои деньги. Мне приходили письма и звонки с претензиями – почему в SAP нет той или иной функциональности. И оказывалось, что она уже года 4, как есть. Почему это происходит – сложно ответить. Возможно, это и недоработка SAP – мало рассказывают, мало просвещают. Иногда – как это ни печально признавать - это связано с партнерами, с консультантами, которым выгоднее сказать, что в SAP чего-то нет, потому что они побольше заработают на том, что вам что-нибудь допишут.

А второе мое открытие – то, что клиенты российские мало знают о том, как работать с SAP, чтобы то, чего нет, а вам надо, появилось в стандартном решении SAP. Не сегодня, так завтра. Притом, что программы работы с клиентами, взаимоотношения, коммуникации в SAP существуют лет 20, не меньше, и работают постоянно. Но в нашей стране почему-то это все идет с большим трудом.

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

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

Типичный пример. Намедни мы долго общались с нашими любимыми клиентами на тему «аттестация рабочих мест». Все знают, наверное, что сейчас есть такой закон, и все возмущаются, что в нашем решении ACM такого модуля нет. Но есть другой модуль, тоже из трех букв, как всегда в SAP, называется HES – и в нем есть функционал аттестации рабочих мест. Правда, после обсуждения уже детального понятно, что его надо доработать, чтобы он соответствовал нашему уникальному законодательству. Но это уже доработка, а не разработка с нуля.

Что это нам доказывает? Прежде, чем принимать решение о собственной разработке, надо посмотреть другие решения, другие версии в SAP. Есть ли альтернативное решение? Может быть, если речь идет об отчете, который нужен 1 раз в год, проще один раз в год нанимать для его подготовки специалистов на аутсоринг, а не вкладываться в разработку, которая будет нужна лишь несколько дней в году?

Очень часто забывают, что на условные 100 рублей, потраченные на разработку, придется еще 500 рублей на поддержку, потому что с каждой новой версией SAP, скорее всего, самостоятельную разработку придется самостоятельно переписывать, поддерживать изменения.

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

Правда, тут же возникает вопрос: что делать с изменениями законодательства? Иногда они происходят с крайней динамичностью. Кстати, у SAP есть на support-портале есть функция уведомлений о таких изменениях. Как выясняется, о ней мало кто знает, хотя она там реализована  уже много лет назад. Достаточно нажать на кнопку, и вы увидите, какие изменения произошли в законах выбранной вами страны или всех стран сразу.  Поскольку, как вы знаете, в основном, изменения законодательства поставляются в виде OSS-нот, у SAP есть два вида нот, связанных с изменением законодательства. Один из этих видов сообщает о том, что SAP знает об этом изменении законодательства, мы над ним работаем, и примерная дата выхода обновления – вот она. Дата, конечно, зависит от сложности обновления. Но если вам хочется узнать, знает ли SAP об этом, работает ли над этим, зайдите, там есть список нот. А дальше, когда все уже выполнено, тут же публикуется уже реальная нота, что изменения законодательства отражены в решении.

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

Если мы собираемся что-то внедрять, начинать какой-то проект, как узнать, а не планирует ли вендор какие-то аналогичные разработки? Например, в прошлом году SAP только по странам СНГ выпустил обновления, отражающие более 60 изменений законодательства в России, Украине, в этом году Казахстан добавляется. Россия по этому параметру впереди планеты всей – у нас количество изменений в законодательстве в полтора раза выше, чем в Бразилии, в 2 раза выше, чем у Китая, и в 4 раза выше, чем у Индии. Про Германию и Францию я даже не говорю. В этом году, я думаю, мы рекорд превысим. Уже в первом квартале более 30 изменений, и дальше прогнозируется не меньше. Уже сейчас в системе почти 600 разных нот про изменения.

Посмотрите спектр решений, которыми мы занимаемся. С одной стороны, это ERP, HR – электронные счета-фактуры, торг-12, комиссионная торговля с валютным контролем. С другой стороны - отраслевое решение для банков, облака, SuccessFactors, или, скажем, специальная функция выверки расчета   заработной платы на HANA – это, по сути, новый интерфейс, который позволяет с HR работать и уменьшить стоимость лицензии. Это для простых пользователей, не для HR-специалистов. Или, например, возможность пользователя поменять свои персональные данные. Или закупки – функциональность SRM, в соответствии с законом 223 ФЗ. Мы также завершили работу по переводу решений SAP ERP и SAP ERP HCM на казахский язык. Проект длился два с половиной года,  мы работали с Министерством культуры и с Академией наук Казахстана. По сути, мы создали казахскую IT-терминологию, потому что ее практически не было. Выходит, что SAP, частная компания, для развития казахского языка сделала  на данный момент больше, чем кто-либо в мире.

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

Следующий вопрос: можете ли вы повлиять на развитие стандартов?

Иными словами, как сделать так, чтобы необходимая вам функциональность была реализована вендором, в стандартном решении, а не вашими собственными силами? Ответ однозначный из двух частей состоит. Первая часть: да, можно. А вторая часть: нужно, на самом деле.

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

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

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

При этом надо понимать, что у всех компаний требования разные, и иногда запросы из разных стран противоречат друг другу. В SAP есть 4 основные программы – они работают уже много лет, но о них надо знать и в них нужно попасть. Такие же программы работают для любого базового функционала. Если вы работаете с нами по локализации, мы с вами говорим по-русски, и общаемся вот здесь, я имею в виду, в Москве, в Питере. Я предпочитаю в Питере, я сам оттуда. А если вы работаете с базовым функционалом, то понятно, что там язык общения – английский, и либо это удаленно, либо где-то от Вальдорфа до Пало-Альто, от Шанхая до Бангалора.

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

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

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

Где найти информацию?  Хороший вопрос. Сразу вспоминается Козьма Прутков: нельзя объять необъятное. Есть новостная лента, есть портал для клиентов, есть специализированные рассылки – на них можно подписываться, и тогда вы всегда будете в курсе нашей работы и изменений в наших продуктах, в том числе – по пакетам поддержки.

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

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

В России почему-то это не происходит. У SAP много было попыток организовать эту юзер-группу, но они как-то не активны. А нам нужно общаться с клиентами, целенаправленно и продуктивно. Поэтому мы организовали такой совет. По сути, это юзер-группа, но здесь инициаторы – мы, а не клиенты. И участники этой группы – это те, кого мы приглашаем. Туда попасть несложно. Главное - активно работать, участвовать в заседаниях, выдвигать предложения по развитию наших продуктов. Внутри группы работаем по разным направлениям – и HR, и поставки, и финансовые решения.

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

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

АНДРЕЙ ТРЕГУБОВ
SAP Labs
Директор Globalization Services
Андрей Трегубов занимает должность директора подразделения Globalization Services в SAP Lab CIS. Обладает опытом работы в сфере системного анализа и вычислений, занимал высокие руководящие и исследовательские посты в сфере ИТ, имеет уникальный практический опыт. С 1998 года занимается сложными внедрениями ERP-систем и решениями для управления логистическими цепочками. Андрей имеет богатый опыт в области управления программами и проектами в больших международных компаниях.