Аксель Ферст
Клиентская история (ERP on HANA)
Докладчик: Аксель Ферст
Проект по переводу SAP ERP на HANA — это очень интересный опыт, который можно использовать и при ведении других проектов. Нужно иметь в виду, что все, что SAP предлагает клиентам, мы первым делом опробуем на своих собственных бизнес-процессах и проектах. Мы являемся первыми адептами HANA. В 2012 году мы начали переход на эту платформу, переводим туда разные платформы CRM, в 2013 году начали планировать перевод ERP-систем. То есть, мы сами себе клиент, SAP runs, SAP first — «SAP» использует решения «SAP» сначала у себя. Мы не будем ничего предлагать другим, не оттестировав это у себя. Иногда это болезненно проходит, но что поделать? С другой стороны, проделав это все самостоятельно, мы знаем все возможные проблемы у клиентов и уже на своем опыте наработали их решения. Бесспорно, такой подход помогает нам становиться только лучше.
Например, у нас разрабатывается множество мобильных приложений для внутреннего пользования, для персонала. Их можно загружать из нашего внутреннего магазина для сотрудников. Если приложение установлено, я хочу просто кликнуть на нем и использовать, без всяких усложнений типа ввода логина, пароля, ключа. И очень хорошо, что SAP тестирует все выходящие продукты сначала внутри себя, потому что это дает возможность проверить — да, мы действительно даем клиентам возможность использовать качественные, удобные, простые в работе решения. Ведь сегодня, если пользователь не устанавливает сразу взаимодействие с приложением, он не будет ничего проверять и разбираться — он просто его удаляет. Важно создавать и предлагать качественные, быстро работающие решения, это наша задача, над которой работают наши разработчики и консультанты. И должен сказать, что имплементация решений SAP у нас же, у себя, проходила довольно болезненно.
Мы используем специальное решение HANA Enterprise Cloud, облачное решение Cloud for People, HCM, и мы переходим полностью на HCM-систему в 2016 году. Cloud for Customer, гибридное решение, CRM-решение, мы приобрели компанию Ariba — поставщика облачной платформы для электронных торгов, и купили также компанию Сoncur — разработчика Trade & Expense (T&E) на облачной платформе. То есть мы сначала в Concur вложили много денег для самостоятельной разработки, а потом приобрели. Бывает и так — получается, что мы напрасно вкладывали деньги в собственные разработки, так как в итоге в результате приобретения получили готовое решение. Такое бывает, ничего с этим не поделаешь. Вот в каком направлении мы идем — все переходит на облако в компании «SAP», и вот таков переход — количество серверов будет уменьшаться в будущем. Мы сейчас находимся в переходном периоде.
ERP на платформе HANA — это single-instance решение: одна ERP-система, много пользователей, масса транзакций проходит через эту систему, и мы пользуемся практически всеми модулями ERP-системы при таком раскладе. Также учитываем в данном контексте 30 с лишним downstream-систем, которые нужно тестировать и интегрировать в дальнейшей перспективе.
То есть мы не просто мигрировали базы данных на HANA. Тут возникли огромные проблемы — как обхяснить бизнесу, почему мы огромные деньги и время потратили на перевод баз данных на HANA. Нужно было продемонстрировать бизнесу quick wins, быстрые победы, чтобы их убедить в том, что это действительно сделано не зря, а также сделать апгрейд технический. Необходимо было организовать процессы fast close и создать бизнес-приложения, так что некоторые решения были потом использованы в реальной базе данных.
Непрерывность бизнес-процессов, соинновационная программа, которая осуществлялась разработчиками при участии специалистов SAP, позволила нам накопить самый передовой опыт реализации и внедрения. Мы попадали в ряд ситуаций, которые обсуждали с разработчиками, что, бесспорно, послужило источником передового опыта и лучших практик.
Каковы ключевые сложности? Как я уже сказал, у нас большое количество систем работает совместно, огромное количество клиентского кода. Если поговорить со специалистами по продажам SAP, клиенты используют стандартный подход. В SAP произошло то же самое, что происходит практически везде у каждого клиента. Если бизнес заявляет: «Мы хотим это сделать вот так», приходится внедрять клиентский код. За 10 лет накопился большой объем того, что не используется, но он необходим — значит, нужно осуществлять миграцию, чтобы все работало. Так что это оказало, бесспорно, большое влияние на ход проекта и разработок.
Пришлось выполнять дополнительный объем работ по тестированию. Также мы использовали самые продвинутые аппаратные технологии, однако поставщик аппаратного обеспечения не оправдал наши ожидания, и мы поняли это не на ранних этапах.
Программа реализуется на международном уровне, не в четырех часовых поясах мы работаем, а в восьми. Б ыло очень интересно все организовывать в таких обстоятельствах, и потребовалась техническая миграция дополнительных изменений в масштабах программ, приходилось добавлять туда дополнительные вещи.
Цели — как я уже сказал, запуск 20 августа, вне зависимости от проблем и сложностей. Дата была обозначена, и если можно было это отсрочить, то ровно на полгода, и никак иначе, по ряду юридических приичин, в том числе — условиям соответствия SOX. Практически, переностить было невозможно, в презентациях везде говорилось, что мы выйдем в эксплуатацию ERP на HANA 20 августа 2013 года, так что выбора у нас не было. Мы осуществили довольно существенный прогресс в плане быстрого закрытия финансовых вопросов разработки приложений на HANA. В принципе, если бы этого не было бы сделано, тоже бы этот вопрос решался, другое дело — каким образом.
Ключевые решения и достижения по этим решениям. Мы вывели из обращения один миллион строк клиентского кода — более 70 % объема. Мы заархивировали более 2 Терабайт данных из систем производственных. До этого мы концепцию архивирования не использовали по техническим причинам, по аппаратным ограничениям — именно они мешали нам этот проект реализовать в полном масштабе.
Время импорта данных снизилось на 40 часов. На обычной базе данных миграция занимала бы неделю, что было неприемлемо. SAP HANA работает, бесспорно, быстрее, чем любая иная база данных. Тесты на производительность показали отличные результаты при пиковой нагрузке и не только. 3 тысячи тест-кейсов были проведены, в них принимали участие более 800 тестеров. Их тоже нужно было скоординировать, так что это было «упражнение» весьма масштабное. Нужно было убедиться в том, что система не работает, по крайней мере, не медленнее, чем предыдущая. То есть надо было посмотреть, насколько высоко быстродействие базы данных. Мы, конечно, знали, что оно лучше, но не были уверены, поэтому проделали вот такое упражнение «single performance test» и «Маслоу тест», регрессионное тестирование, dry run.
Мы должны были убедиться в том, что не будет никаких перерывов в работе компании, обычной работе компании, поэтому проделали все с прицелом на то, чтобы избежать различных перерывов в работе. Как я уже неоднократно рассказывал, это было масштабное упражнение, более 300 тикетов было создано. Вообще‑то мы ожидали больше тикетов и уведомлений. Из 3 000 тест-кейсов 300 — это не так и много. Получается, что подготовили мы все достаточно неплохо. И получили одобрение без всяких проблем. 6,7 терабайт база данных была до миграции, после ее очистки объем снизился на HANA до 1,8 терабайта.
Самое главное вот что. Каждая база данных отвечает за определенную транзакцию, операционная система там находится и так далее. То есть мы думали, что 6 терабайт — это хорошо, и знали, что освободить можно примерно половину, иначе это окажет влияние на производительность. Но мы не знали, насколько получится уменьшить базу по сравнению с этими исходными 6 терабайтами. Но была проблема — 6‑терабайтный бокс, который был в IBM выделен, не сработал. Они были сертифицированы для 34 терабайт, и было сложно это сделать при наших объемах. Мы начали этот проект в апреле, а выяснилась эта проблема уже в конце мая. Учитывая сжатые сроки — запуск 20 августа — мы оперативно начали с бизнесом обсуждать, какие данные, накопившиеся за 10 лет, можно удалять и заархивировать. И мы поняли, что с юридической точки зрения должно обязательно находиться в системе, а что можно заархивировать. Некоторые данные даже годичной давности, полугодичной давности необходимо хранить в системе. Архивирование не значит, что данные ушли — просто теперь, если требуется получить эти данные из архива, они доступны не за 0,2 секунды, а за 2 секунды, так как требуется их предварительно разархивировать.
Нам нужно было убедить бизнес в том, что архивирование решит проблемы и не создаст новых препятствий. У нас есть архивы, просто можно на компакт-диске эти данные хранить и так далее. Разными методами мы снизили количество данных путем архивирования, удалили ненужный клиентский код. Важно было провести IHS, этап post go life, то есть после запуска. Останется
