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

«Ре­ко­ме­нда­ции по обе­спе­че­нию бе­зо­па­сно­сти и контроля SAP HANA»
Дмитрий Буслов:
(1) Автор начинает с того, что HANA — это СУБД, позволяющая хранить записи в колонках и работающая в оперативной памяти. Я бы, хотел сделать акцент на том, что HANA — не просто СУБД,...
«Различие между двумя текущими версиями HANA»
Олег Точенюк:
Спасибо конечно... я вот не понимаю как консалт выживает в этом мире, когда есть такой чудесный традиционный сайт help.sap.com/ :-)
«Игровой ролик: SAP для Retail»
Александр Дублин:
Суть ролика: если хотите спать в рабочее время, унижать подчиненных, то с решением от SAP вам это будет удобно. Сценарий ролика - продолжения истории: top-lap.livejournal.com/502664.html

База знаний

Клиентская история (ERP on HANA)

Предыдущая Следующая
Просмотров 2458 Комментариев 0

Клиентская история (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, то есть после запуска. Останется ли система стабильной, и будет ли она стабильно, хорошо работать? Это был риск тоже. Но на этом этапе мы имели хорошую поддержку.

У нас был 12‑уровневый ландшафт, потому что мы 12 систем мигрировали рабочих. То есть по умолчанию у нас был 5‑уровневый ландшафт обычный, еще ландшафт разработчиков, проектный, «песочница» для ранних тестов, для переноса кода. Все системы нужно было учесть, и чем ближе было к конечной дате, тем более важным был вопрос roll-back, отката. То есть, если вы начинали миграцию на реальный ландшафт и потом принимали решение по какой‑то причине остановиться, все, что было разработано в это время, исчезало. Что было разработано в HANA — при откате эти решения не возвращались. Это был самый крупный риск, буферов у нас тут никаких не было. С первого дня, когда мы начали этот подход использовать, единственный буфер у нас был — это уикенд, два выходных дня, больше ничего.

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

Как я уже сказал, мы снизили размер базы данных, после миграции она снизилась до 1,8 терабайта (с изначальных 6). То есть коэффициент сжатия более 2, при переходе на HANA с обычной базы данных. Мы больше всего боялись того, что у нас не впишутся в 4‑терабайтный бокс наши 6. Ежемесячно мы получаем 50‑100 ГБ информации. То есть надо было получать потом другое, модернизированное аппаратное обеспечение, но если данные будут поступать такими объемами, то насколько этого хватит? А если потом скажут, что база данных растет в объемах очень быстро, и негде будет потом хранить данные, потому что они поступают слишком большими объемами? Это был риск. Но HANA постоянно развивается и модернизируется. Наша база данных сейчас составляет 1,5, мы постоянно новые релизы выпускаем, и коэффициент компрессии постоянно увеличивается, сжатие файлов улучшается. Кроме того, мы продолжаем удалять ненужный клиентский код и постоянно уменьшается объем данных, что хорошо, это хорошая новость.

Как я уже сказал, мы много чему научились здесь, это было масштабное упражнение для нас. Вообще, мы об этом даже не думали, когда начинали такую программу. Мы часто рекомендуем клиентам: используйте архивы, удаляйте ненужный клиентский код. И вот мы когда сами начали этим заниматься, четко теперь уже это представляем. У нас есть специализированная команда, 10 IT-специалистов, которые занимаются оптимизацией клиентского кода, «custom code life cycle management», чтобы мы соответствовали также различным юридическим требованиям. Мы создали команды специалистов, которые теперь в этом вопросе хорошо разбираются. Максимальное время простоя системы составляет 3,5 дня — пока довольно много, но уже очень много сделано для оптимизации этого показателя. Когда речь идет о миграции баз данных, нужно много чего останавливать, удалять данные — в это время нельзя пользоваться системой. То есть это нужно делать последовательно. Здесь время не сэкономишь. А где можно сэкономить? На апгрейдах. То есть сначала сделать апгрейд системы, это сэкономит вам время. Будет гораздо проще, если у вас апгрейд делается отдельно, а миграция — отдельно. Такой процесс миграции сам по себе занимает около 18‑20 часов. Есть и миграция, которая занимает очень мало времени — простой может составлять лишь 1‑2 часа. То есть базы данных работают параллельно в процессе миграции, и потом осуществляется переключение на реальную базу данных, и она может продолжать эффективно работать. То есть доступность данных практически всегда есть, и дальше нужно проделывать тесты на совместимость, на стабильность.

Мы создали отчеты, которых ранее в системе не было — они позволяют оценить, хватает ли у всех данных после миграции, не утрачено ли что‑нибудь. Осуществили разработку, потом передачу данных, проверки спотовые и вывели базу данных на полнофункциональный режим. Это показывает, что можно запустить несколько процессов параллельно. У нас не используется уже холодный standby, используется горячий standby, для всех систем. То есть пользователь не замечает того, как система работает, для него это происходит без всяких перерывов.

У нас был создан специальный контрольный центр управления IT-операциями, где мы привлекали сотрудников, работавших со всеми ключевыми подразделениями компании, для того, чтобы этот процесс был сделан максимально просто и легко. Как я уже сказал, мы много тестов проделали, что мы должны были убедиться в том, что основные транзакции осуществляются так же быстро, как и раньше, или лучше. Мы получили очень неплохие результаты, но в некоторых областях увидели возможности улучшения. Например, на 30 % медленнее в некоторых случаях работало, чем раньше. Но потом мы со временем эти показатели улучшили. И когда мы вывели это в общую эксплуатацию, мы разогнали это еще на 40 %, и транзакции основные у нас обрабатываются на 40 % быстрее, чем раньше.

Итак, выводы.

  1. Нам потребовалось 5 месяцев. В августе мы запустили систему в эксплуатацию. Я не рекомендую вам так делать, так же, как мы. Стоит, наверное, на это потратить чуть больше времени, подстраховаться, буфера различные поставить «страховочные», в кавычках, и проделать много процессов — последовательно или параллельно, чтобы не было так сложно и болезненно, как у нас. В любом случае, мы запустили нашу программу GL в этом году, реализовав ее за 2,5 месяца. В начале это было так же болезненно, потому что сроки запуска были обозначены и задерживаться нельзя было даже на неделю. F-Com — значит, F-Com. Все должно быть сделано вовремя.
  2. Большинство транзакций существенно быстрее осуществляются, и сейчас мы можем уже осуществлять отчетность и бизнес-аналитику в реальном времени. Раньше у нас этого не было. Это одно из существенных улучшений — получение отчетности в реальном времени, по ряду параметров.
  3. Важные уроки дали тесты на производительность, разные команды. Мы должны были убедиться в том, что HANA действительно работает быстрее, как обещали разработчики. Было очень интересно наблюдать это. За 5 месяцев, в течение 5 месяцев она стала работать в 3,6 раза лучше, чем та база данных, которая использовалась ранее.
  4. Техническая подготовка, архивирование, устранение ненужных строк клиентского кода — это то, что нужно всегда принимать во внимание при миграции баз данных. Это постоянный процесс. Многие клиенты об этом забывают, не уделяют этому должного внимания. Тем не менее, если этому уделять должное внимание, это снижает время на тестирование и, в общем, упрощает ваш процесс. Если вы устраняете старый код, вам уже не нужно будет его там тестировать впоследствии, так что это убыстряет общий процесс.
  5. Обновления. Важно провести обновления до того, как вы начнете проект по миграции, это будет проще. Проведите тесты на нестабильность, автоматические тесты на регрессию — они очень упростили жизнь, потому что раньше‑то все делалось вручную.
  6. Автоматизация тест-кейсов позволила нам сократить объем этой работы без потери качества. Было раньше меньше, чем 40 % тест-кейсов автоматизировано, а сейчас больше 80 %. Существенный общий прирост гораздо выше получился, чем раньше.
  7. Доступность ресурсов всегда важна. Независимо от того, что IT в Вальдорфе находится, поддержка в Индии, но они работают как одна команда. Это было сделано очень быстро, и каждый день на встречах мы говорили разработчикам, что нужно сделать, они общались с нужными людьми, и на следующий день у нас работал update. Такой подход работал потому, что все люди были на месте. Dry run был очень важный, и переход на новую базу данных. Об этом должны знать IT-специалисты. Нужно сделать, по крайней мере, один прогон, один dry run, чтобы бизнес знал, как это происходит.
  8. Управление стейкхолдерами тоже важно очень. В этом контексте данный вопрос рассматривается как политически важный, это подразумевает вовлечение всех нужных заинтересованных сторон. Каждую неделю мы должны устраивать встречи с руководителями, с участниками управляющего комитета, видеть, отчитываться по прогрессу, по результатам работ. К этому подключали всех заинтересованных лиц, всех топ-менеджеров, из IHS, из IT, из бизнеса. Все были доступны и принимали нужные решения. Так что информация им предоставлялась всегда своевременно и быстро.
  9. Управление изменениями. Мы сделали это во второй фазе программы — не переключались на транзакции HANA, иначе, с точки зрения тестирования, пришлось бы два раза приложить эти усилия. Тестировали сначала старое решение, потом новое. В любом случае, требовалось решение, разработать новое мы не успевали и решили сохранить существующее, а на втором шаге перейти на новые транзакции.
  10. И, конечно же, это должно полагаться на экспертизу специалистов в бизнесе и IT, чтобы приносить финансовые выгоды. Это было довольно сложно и болезненно, потому что часто ресурсы становятся вам недоступны. Возникает вопрос: какая программа приоритетней, на какую программу выделять средства, за счет каких? В данном случае это было выделено на перенос SAP ERP на HANA.