Как работать стабильно и без рисков в IT-среде

Меня зовут Маркус Александр Функе, я работаю в SAP Active Global Support в регионе EMEA и сейчас развиваю систему поддержки SAP Mission Control Center.

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

Управление жизненным циклом приложений

Управление жизненным циклом приложений – это IT-процесс, который поддерживает требования по развертыванию процессов. В этом процессе есть четыре основные зоны, которые должны работать стабильно и без рисков в IT-среде.

Во-первых, управление IT-сервисами. Когда мы говорим про сервис-менеджмент, про управление IT-сервисами, мы говорим про ключевую функцию, которая поддерживает не только Help Desk, но и другие системы.

Управление инцидентами, проблемами является интегрированной частью ITIL Desk, как и управление сервисами. Таким образом, в результате инцидента вы сможете сгенерировать запрос на изменение. В конечном счете, когда запрос на изменение создан, он должен быть спроектирован, задокументирован, протестирован и правильно и тщательно развернут.
Соответственно, мы должны уметь управлять тестированием реализаций в определенный момент времени. Для того, чтобы этим процессом руководить, мы строим фабрику – это тоже терминология, «SAP-фабрика».

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

Управление большой фабрикой

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

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

Иногда необходимо отследить: есть ли недостатки в каком-либо процессе, IT-менеджеры должны быть способны это узнать. Отгрузка не может быть осуществлена, и это можно отследить в системе до того, как в компанию позвонят представители бизнеса и скажут: «Вы знаете, тут у меня скопилось 700-800 заказов, которые нельзя никак выполнить, помогите мне». Это требуется определить заранее, быть готовыми к таким событиям.

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

Help Desk как рабочий продукт

SAP предлагает центральный инструмент SAP Solution Manager, который может поддержать все четыре ключевых процесса. По сравнению с другими продуктами SAP Solution Manager уже является рабочим продуктом, для мониторинга можно использовать Help Desk. В то же время возникает вопрос: какие ключевые процессы компания должна запускать в первую очередь, в какие процессы нужно инвестировать? Полный технический контроль над внедрением изменений и тестированием – нужно вкладывать именно в них.

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

Итак, я представил суть управления жизненным циклом IT-приложений и интегрированный IT-менеджмент.

Чего не хочет бизнес

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

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

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

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

Как это дальше будет влиять на ландшафт? Ландшафт порождает другие проблемы, потому что нужно подтверждать изменения и параллельно ими управлять. Три вещи делают развертывание IT-решений безопаснее на 80%, чем обычно, если следовать рекомендациям и накопленному нами опыту.

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

Требуются перемены к лучшему

Рассмотрим первый компонент стратегии. Это стратегия релизов. У компаний часто существует стратегия релизов. Вопрос лишь в том, насколько качественной она является.

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

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

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

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

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

Мы видим то, что уже наблюдали, – запрос на изменение, его реализация. Календарь релизов может выглядеть примерно таким образом. Брейк-фиксы тогда, когда готовы, небольшие исправления в день «Д», один-два раза в неделю. Большие релизы потребуют даунтайма. Вы видели в демонстрации, что для брейк-фикса мы выбрали в качестве примера срочное изменение. Это было сделано без всякого прерывания операции. Для небольшого релиза вы выберете один статус, для крупного релиза – другой. Это определит всю логику, и в конфигурации вы сможете определить, что у срочных изменений всегда есть приоритетность, они внедряются в производство после тестирования. Такая логика стоит за нашей демонстрацией. Это слайд, который показывает идеальную ситуацию.

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

Вам нужна вторая система

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

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

Так что если вы хотите быстро реализовывать изменения, вам обязательно нужна вторая система разработки. Это поможет решить проблему внедрения изменений. Такая система должна работать для того, чтобы определять конфликты в нужном порядке. Если вы будете делать это вручную, IT быстро «перегреется», что станет причиной больших проблем для бизнеса.
У нас сейчас есть очень много тестовых систем и способов внедрения второй тестовой системы. Mercedes-Benz или Porsche можно создать в системе тестирования, это будет очень изящно и здорово, но стоить денег таких же, как сами Mercedes и Porsche. Поэтому многие выбирают более оптимальные решения со вторыми системами только для бизнес-критичных задач.

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

Даунгрейд и другие проблемы

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

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

Чисто логически необходимо использовать какой-то механизм обнаружения, который будет находить конфликты и сможет помочь избегать их автоматизированно. Такая возможность есть, она уже работает и была протестирована на тысяче клиентов. Она называется ChaRM: Retrofit и существует, для того чтобы управлять изменениями на техническом уровне, выявлять и устранять конфликты. Ее приоритетность является основной, высшей. В сочетании Downgrade Protection и ChaRM: Retrofit вы сможете решить 90% конфликтов, которые происходят в реализации проектов непоследовательным образом.

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

Например, удачно использовала такой подход одна американская компания из моей практики, у которой работает Global HR. В этой системе постоянно происходят изменения, потому что компания присутствует в 90 странах, постоянно возникают юридические изменения. В этой связи систему нужно обновлять, содержать в самом актуальном виде. В компании регулярно меняются платежные ведомости, прочие документы. 20 тысяч транспортов нужно организовать для того, чтобы обновить ландшафт, соответствовать всем юридическим законодательным требованиям. Около 18 тысяч транспортов было необходимо полностью автоматизировать.

Сделать это было очень просто. В компании посчитали, что они порядка 1,5 тысячи человеко-дней сэкономили, в деньгах это весьма существенная сумма. Так что это хороший способ экономить средства, если заниматься процессом каждый день. В емких длинных проектах часто это экономит большие деньги. Даже компании, которые реализуют 50-60-200 транспортов в неделю, могут сократить свои расходы на данные цели до минимума.

Нужно также упомянуть еще об одной, крайне важной теме. Это технический даунтайм. За последние два года компания SAP существенно улучшила возможности апгрейда. Технический даунтайм апгрейдов существенно снизился. Почти в каждой Use Case мы улучшили функциональность, которая снижает техническую недоступность, даунтайм обновления до одного-двух часов. Бизнес-даунтайм можно сделать и еще меньше. Для больших компаний, например, автомобильной промышленности, это актуально.

Несколько слов, которые касаются проактивного внедрения пакетов расширения HP. Когда вы будете планировать апгрейд и применять Enhancement Package, должны четко представлять изменения еще до того, как будете устанавливать данный пакет расширения.

В Solution Manager добавлена функция, которая называется EHP Scope and Effort Analyzer. Она использует ту же самую логику, о которой говорилось ранее, только в проактивном режиме. Идея заключается в том, что все технические данные окажутся в системе, после чего будет составлена техническая смета. SAP сделает технический анализ, и вы получите результат, сможете определить транзакции, которые будут затронуты. Или же, например, если вы используете клиентский код, custom code, то сможете определить, какие объекты изменялись. В данном случае у вас будет очень хорошая возможность предугадать, механизм предупреждения влияния этих изменений на систему, даже до того, как вы начнете первый транспорт.

Есть и другие компании, которые тоже предлагают такую услугу. Да. Но компания SAP предлагает лучший функционал в рамках стандартного расширения, поддержки. Поэтому вы можете прибегнуть к нашим услугам, подумайте, посчитайте, что это сулит вам, какие выгоды. Это, прежде всего, соблюдение стандартной практики и процедуры. Нас уже многие годы просили об этом – использовать специальный инструмент анализа, который будет определять влияние и последствия перемен в начале. Мы его сделали – это EHP Scope and Effort Analyzer.

Следующий вопрос – как организовать тестирование. Прежде всего, необходимо понять, что мы предлагаем разнообразные инструменты тестирования, имеющиеся в наличии. Это, в частности, magic tool, инструмент BPCA, который можно использовать двумя способами: технически и анализируя риски.

Основной вопрос: как компания SAP поддерживает тестирование, которое осуществляется интегрированным образом? Мы развивали следующий сценарий: имеется документация бизнес-процессов. В идеальном сценарии нам помог Business Process Change Analyzer, и мы изучили, какие инструменты тестирования здесь можно использовать. Это Test Workbench. Мы использовали автоматизированные способы решения задачи.

Если у вас инструментов управления тестированием пока нет, совершенно не обязательно покупать их у стороннего производителя, потому что Test Manager в SAP Solution Manager предоставляется как часть программы обслуживания.
Если у вас работает HP Quality Center или Rational Software, эти решения можно интегрировать. Если же вы используете платформу SAP, лучше оставаться на ней. Дело в том, что SAP Solution Manager совместим с SAP Workbench и Quality Center.
На сегодняшний день существует также возможность интегрировать в наши решения третьих производителей. Business Process Change Analyzer – тот инструмент, который определяет побочные последствия таких интеграций, позволяет избежать проблем. Так что, наверное, по этим причинам хорошо использовать HP Quality Center.

Нет правильной структуры IT-процессов? Проблема решаема

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

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

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

Второе. Многие компании боятся повторной документации, им кажется, что придется все повторно документировать. Обычно в ERP-системах используется около 150-170 тысяч активных транзакций. Меньше 10%, наверное. В среднем их количество составляет порядка 200-300 тысяч. Бизнес говорит, что они используют все, и все же они используют далеко не все.

Все это можно узнать. Используя Solution Manager, выполняют анализ  ситуации. Его результат даст правдивый ответ на вопрос, сколько исполняется va01 в день, сколько версий va01 существует, сколько XYZ используется в день. Это часть функций Solution Manager.

В стандартной ERP-системе обычно активно используемое количество транзакций, реализуемых кодов составляет от 2 от 3 тысяч. Однако бывает 200 и  больше. 100 или 200 транзакций составляют 90% из всего объема транзакций. Это значит, что «тяжелое использование» системы начинается, когда используют от 100 до 200 транзакций.

Если вы хотите организовать нормальный тест-менеджмент, создать правильную деловую документацию, обратите внимание на эти 100-200 транзакций, потому что они несут в себе 10-15 сквозных процессов в одном-двух вариантах. Если поднять бизнес-документацию, использовать Solution Manager, изучить эти 10-15 сквозных процессов, использовать структуру для управления тестированием, это можно обсудить с владельцем бизнеса и создать сложную структуру. Начать же следует с вещей, которые наиболее актуальны.

К сожалению, в таком случае, вы не сможете выйти на все 2 или 3 тысячи, но это можно сделать в последующий итерации. Где-то за полтора года вы наберете около 90% нужной документации, просто регулярно проводя эту работу.

В то же время, начиная процесс повторной документации, не нужно выделять это в огромный отдельный проект, стараться все сделать быстро и сразу. Можно это сделать другим образом, используя возможности системы для того, чтобы определить, какое у компании реальное количество транзакций: 200, 100 или 2000, 3000. Определив ключевые процессы, их нужно поместить в структуру. Количество транзакций, которое обычно автоматизируется, – около 200. У сложных клиентов автоматизировано 50-100 транзакций. Если их запустить и протестировать на предмет изменений, влияния изменений, как раз и возникают проблемы, потому что эти транзакции должны всегда работать. И даже если одна транзакция, которая вкладывает 90%, не заработает, будут проблемы, бизнес не сможет работать. Поэтому эти вещи нужно всегда принимать во внимание.

Теперь вопрос: как этого всего добиться? При помощи Two Value Releases Per Year. Как уже говорилось, нужно планировать два улучшения и увеличения ценности в год. Если много процессов разрабатывается параллельно, сделайте вторую систему для разработки, используйте функции Retrofit для того, чтобы контролировать изменения, избежать конфликтов между процессными проектами.

Тестировать следует только важные вещи, рекомендуется использовать функционал Business Process Change Analyzer для того, чтобы выявлять все сторонние побочные эффекты.

Занимайтесь автоматизацией регрессионного тестирования. Это тема сложная, но с ней вполне можно справиться, если не увеличивать количество транзакций больше оптимального для вас уровня, например, 50%. Затрагивать нужно только ключевые бизнес-процессы.

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

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

МАРКУС_АЛЕКСАНДР ФАНКЕ
SAP AG
 
Доктор Маркус-Александр Фанке является частью Management Team в SAP Active Global Support. В качестве директора программы Маркус помогает выстроить новое ядро SAP Support – EMEA MCC (Mission Control Center), возглавляя команду по управлению жизненным циклом приложений (ALM). С того момента как Маркус присоединился к SAP в 2001 году, он с успехом создал представительства SAP Active Global Support на нескольких развивающихся рынках, таких как Южная Африка и Ближний Восток. Он успешно запускал расширенные пакеты поддержки: SAP MaxAttension и SAP Active Embedded на локальных рынках.