Робин Шонвальд

В данном докладе мы рассмотрим основные аспекты процесса, который называется «Управление жизненным циклом приложения» (ALM) и включает в себя создание требований, реализацию, внедрение, IT сервис-менеджмент, обновление и модернизацию решений. Мы посмотрим, как эта работа организована в компании SAP, какие передовые практики в работе с клиентами уже существуют.

Идея ALM (управление жизненным циклом приложения) заключается в том, что у нас есть сквозные процессы, которые идут с самого начала до завершения разработки приложения. Этот жизненный цикл может длиться достаточно долго и порождает большой объем информации, которую необходимо организовать. Первый вопрос — как это сделать?

Второй вопрос – вовлечение конечных пользователей бизнеса в этот процесс. С технической точки зрения возникает следующая задача: сделать так, чтобы клиенты наиболее точно определили процессы, которые необходимы для реализации их требований (user requirements). В работе со стандартным программным обеспечением SAP мы используем термин «gap-менеджмент» (управление разрывами), суть которого — в определении, что в существующем решении необходимо дополнить, чтобы создать индивидуальное решение для клиента. Некоторые клиенты стараются максимально использовать стандартное решение, другие - выйти за эти рамки. Как определять, что необходимо дополнить – это отдельный вопрос.

Третий момент. Частью ресурсов проекта являются специалисты, которые должны составлять новую документацию — ту, которой в начале проекта по какой-то причине не было. И SAP Solution Manager должен использоваться и как инструмент для создания документации. Мы рассмотрим этот аспект в докладе «Документация бизнес-процессов при внедрении SAP»: какие бывают бизнес-схемы, как они используются.

Есть стандартная модель SAP, называется «Accelerated SAP» (ASAP), и в ней выделено семь фаз. Начинаем мы со сбора требований бизнеса, с изначального планирования, документирования требований, затем идет этап тестирования, потом уже внедрения. Третий шаг в этом процессе – документирование требований бизнеса. Есть специальная фаза, которая называется определение бизнес-схем. Что такое бизнес-схема? Это отражение бизнес-процессов в инструменте, используемом для ведения проекта — в данном случае этим инструментом будет SAP Solution Manager.

Solution Manager поддерживает трехуровневую иерархию: проект, потом бизнес-сценарий (один или несколько), дальше – бизнес-процессы. У бизнес-процессов есть определенные шаги, в каждом процессе - свой. Такова бизнес-схема.

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

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

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

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

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

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

Рекомендация
Сделать тестирование, основанное на рисках, чтобы выявить наиболее важные бизнес-процессы, которые нужно оттестировать в первую очередь.

Третья часть – документация бизнес-процессов. Допустим, новые эксперты — из компании SAP или какой-то другой, не важно — хотят изменить вашу систему. Для этого они должны знать ваши процессы, оценить, насколько вы кастомизировали внедренное решение, насколько вы отклонились от стандартного решения, добавилось ли к нему что-то. Любой, кто работает с Solution Manager, знает: если есть бизнес-схема, процессы зафиксированы, и можно на этой основе рассказать об изменениях, о документации к ним, и все это находится в едином источнике, в одной системе. Это и есть SAP Solution Manager.

Еще один пример из практики. Многие компании и не знают на самом деле, что происходит у них в системе — мол, используется стандартное программное обеспечение SAP. Так ли это на самом деле? Если у вас есть привязка к реальной системе, вы всегда можете проверить, и все время проверять, чем люди пользуются, что нужно учесть при апгрейде и модернизации системы, и при тестировании тоже. С технической точки зрения в Solution Manager есть функции, которые, если вы документировали свои процессы, позволяют сделать много полезного.

• Анализатор изменений (BusinessProcessChangeAnalyzer) – с его помощью вы сможете проанализировать вашу систему и выявить, какие в ней есть изменения. Мы чисто технически можем рассмотреть и оценить, что менялось. Change Analyzer информирует вас, на каких этапах внедрены реальные изменения. При повторном тестировании системы вам уже не требуется тестировать ее всю — только те части, которые были затронуты изменениями. Это позволяет снижать количество тестов, объем регрессионного тестирования.
• SolutionDocumentationAssistant – этот инструмент помогает определить, какие транзакции реально используются в вашей системе, кто ими пользуются, и как транзакции связаны с бизнес-процессами. В конечном счете, вы понимаете, каковы важные процессы и транзакции документируются, какие – нет, а какие — документируются, но никогда не используются.
• Business Process Monitoring — это то, что стоит рассмотреть с точки зрения клиента, не просто систему, а бизнес-процессы. Обычно как бывает? Анализируется аппаратное обеспечение – нагрузка процессора, емкость жестких дисков и прочие функции сервера. Но если мы говорим о мониторинге бизнес-процессов, а не работы аппаратного обеспечения, то анализируем, например, количество счетов-фактур, инвойсов, которые пока не используются. На основе этого вы определяете ключевые показатели эффективности и отслеживаете эти KPI, с помощью «Business Process Monitoring».

Рекомендация
Все эти функции Solution Manager наиболее эффективны в том случае, если изначально определены и зафиксированы бизнес-процессы.

Таков общий принцип. Теперь рассмотрим, как это работает на практике.

Бизнес-схема. Существуют различные фазы и так далее, но мне бы хотелось показать вам с точки зрения пользователя, чисто технически, как создать бизнес-схему.

В чем роль эксперта по бизнес-процессам? Допустим, у нас есть три больших группы данных. С помощью Solution Manager вы определяете организационное подразделение — например, группу по продажам, которая вовлечена в эти процессы, потом определяете мастер-данные (например, продуктовый каталог, условия ценообразования, маркетинг и так далее). Это необходимые показатели, которые сюда включены.

Тут требуется, конечно же, не одна система: несколько систем взаимосвязаны друг с другом, не обязательно все эти системы от компании SAP, поэтому нужно определять сценарии взаимодействия одних систем с другими. Давайте рассмотрим SAP Solution Manager.

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

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

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

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

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

Рекомендация
Мы всегда говорим нашим клиентам, что оптимально оставаться с максимально стандартным решением, но мир неидеален: иногда лишь в 75% случаев вы можете использовать стандартное решение. Так вот, на первом этапе вы можете взять все из поставляемого контента и подстроить потом изменения так, как вам нужно, вручную, самостоятельно.

Это один из примеров того, как выглядит данная структура бизнес-сценария. Например, планирование спроса. Один из процессов – demand planning, дальше – бизнес-процессы, обработка заказов, сборка заказа и создание запросов, create inquiry. Это транзакции, реальные транзакции, которые существуют в вашей системе, которые имеют отношение к этому шагу, на который я сейчас показал.

Итак, мы рассмотрели первый шаг на пути создания трехуровневой иерархии. Второй шаг – документирование вашего решения (обычно в .pdf, Word или Excel). Ваша модель процессов оживает, работает, и в нее можно уже включать иную дополнительную информацию: тест-кейсы, инциденты, требования, все, что можно отнести к бизнес-схеме.

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

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

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

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

Вопросы и ответы:

– Бывает ли информация избыточной, и какой объем этой информации бывает избыточным, или не используется, или чрезмерно детальный? Или чем больше, тем лучше?

РОБИН ШОЕНВАЛЬД:
– Я считаю, что чем больше информации, тем лучше. В этом и заключается все искусство правильного структурирования информации: транзакции и процессы, которые не используются, вы можете отметить в своей системе. Однако на первом уровне нужно собрать как можно больше информации, которая может вам помочь на дальнейших этапах — например, на этапе эксплуатации. Потом вы анализируете и, если что-то работает не так, как это ожидалось, то можно заглянуть в документацию, которая была создана на предыдущем этапе, и убрать эти данные. При хорошей организации и структуре лучше все-таки иметь больше информации, нежели меньше.

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

РОБИН ШОЕНВАЛЬД:
– Очень хороший вопрос. Business Process Change Analyzer работает на уровне технических объектов Technical Bill of Materials (TBOM), либо технической спецификации. Она создается следующим образом. Вы смотрите на бизнес-процессы в системе, и на первом этапе Change Analyzer понимает, какие объекты используются во время исполнения того или иного бизнес-процесса. Потом он сохраняет список технических объектов, спецификаций на этом этапе. Если вы меняете что-то в системе, то есть возможность проанализировать транспорт. Система знает, что в случае этого транспорта вы меняете этот объект, эту таблицу или что-то еще, вносите изменения. И Change Analyzer смотрит, где используется эта информация, объект, таблица, и обозначает шаги в процессе. Существует два этапа. Первый этап – создание этой спецификации материалов, процессы. Второй — с помощью данного программного обеспечения производится анализ последствий: как повлияют изменения на всю ситуацию. Если вы будете тест-кейсы сохранять в структуре, то Solution Manager сможет вам создать план тестирования буквально одним нажатием кнопки в системе.

– Иными словами, он работает на уровне базы данных?

РОБИН ШОЕНВАЛЬД:
– Да, он работает на уровне базы данных, на уровне технических объектов.

– Мы пытались использовать Solution Manager: создавали TBOM, бизнес-процессы, шаги. У нас было две цели. Первый этап – начать определять объем тестирования, релевантный для конкретного изменения по ответу Solution Manager: когда водишь, образно говоря, систему за руку по транзакциям, она запоминает все вызовы функций, таблицы и прочее-прочее. Когда мы переносим такой-то запрос, система показывает, какие таблицы задействованы на пересечении, и определяет объем тестирования. Мы хотели не определять экспертно объем тестирования, чтобы снизить риск ошибок, человеческого фактора: у всех разный объем работы, опыт и прочее. Второй этап, который мы хотели осуществить после первого – использовать eCATT для автоматизации тестов, убрать рутинную работу по ручному тестированию. К сожалению, мы первый этап не смогли осилить даже с помощь коллег из SAP, потому что столкнулись со следующим. Любое изменение в системе давало такой объем тестирования, который заставлял тестировать весь модуль SD. Например, мы поменяли какое-то поле в интерфейсе заказа («Sales order»), и система показывала, что нужно по SD протестировать порядка 70% функциональности. А вторая проблема — в том, каким образом это все происходит. После того, как изменения проанализированы и определен объем тестирования, мы это протестировали успешно, донесли до продуктивной системы, и в итоге TBOM нужно перезаписать заново, чтобы система «запомнила» внесенные изменения. Это определенный кусок работы, который необходимо выполнять. Когда работает большая команда, тем более с интеграционными модулями, человек 30, например, как у нас в разработке, когда постоянно много задач тестируется, в тестовой системе очень трудно создать среду, которая бы всегда правильно определяла объем тестирования. Это достаточно сложная вещь, у нас этого не получилось. Полгода мы пытались это сделать, и, собственно, отложили до того момента, когда у нас будет положительный опыт, в том числе и в нашей стране. Есть ли в Европе референциальные клиенты, к которым можно поехать и посмотреть конкретно эту вещь, что ее используют именно в том смысле, в котором вы сейчас показывали? Потому что задумка идеальная, мы вообще считали, что это панацея. Мы тратим на это очень много времени, с постоянно плавающим качеством. У нас сейчас около 2 тысяч атомарных тестов репозитория, и ведется это вручную в Excel с описанием по шагам, бизнес-процессам. Практически, это аналог той структуры, которую вы показывали, только это у нас в Excel, и мы сами определяем экспертно объем тестирования, и вручную проводим тесты. Очень трудно заставить людей это делать, потому что они на это тратят очень много времени. Вот такая у нас проблема. Спасибо.

РОБИН ШОЕНВАЛЬД:
– Большое спасибо вам за ваш вопрос и за то, что вы поделились вашим опытом использования данного инструмента. Вы обозначили две проблемы. Когда вносятся изменения в очень важную таблицу, то 70% нужно заново тестировать. Из-за этого мы добавили новую функцию в существующую версию. Если инструмент заявляет, что 70%, 80%, 100% нужно заново тестировать, то в этом случае можно настроить организацию теста таким образом, чтобы ключевые технические объекты были протестированы на самых ранних этапах — например, тест-кейсы. Такой подход гораздо безопаснее и лучше позволяет это организовать. И второй вопрос. Действительно, когда есть такие изменения, мы должны воссоздать TBOM, но только в случае, если вы добавляете новые объекты. Если видоизменяются только существующие таблицы и объекты, этого делать не нужно. Но если все же необходимость есть, нужно организовать тестеров, которые обладают техническими знаниями и навыками, для повторного тестирования, и они перезапишут TBOM именно в этих фазах. Тогда эту работу придется делать не в таких больших объемах. Так что есть способы оптимизировать данный процесс.

– Сколько клиентов, допустим, в Европе, в Германии использует функциональность Business Process Monitoring?

РОБИН ШОЕНВАЛЬД:
Есть статистика немецкой группы пользователей, какими сценариями в SAP Solution Manager они пользуются. По Change Request Manager – 12-14%, и по Business Process Monitoring примерно столько же. В Европе именно через Active Global Support этот мониторинг бизнес-процессов делается. Если посмотреть на все внедрения SAP Solution Manager, глобально, то около 10%, и есть тенденция к росту.

– Является ли Hewlett-Packard Quality Center тем инструментом, который позволит эффективно автоматизировать процессы создания тест-кейсов и их выполнение автоматизированное?

РОБИН ШОЕНВАЛЬД:
– Есть разные решения на рынке, HP Quality Center является лидером в этой области. SAP Solution Manager не очень хорошо себя показывал в тестировании 5-10 лет тому назад, возможности для тестирования у него были ограничены. Поэтому мы решили, что если есть клиент, который хочет автоматизировать эти задачи, мы таким клиентам рекомендуем использовать HP Quality Center. Но с новым SAP Solution Manager версии 7.1 все изменилось. Мы автоматизируем тестирование для того, чтобы сделать такие компоненты, которые были бы и в Quality Center, и в SAP Solution Manager. Поэтому моя рекомендация такая: если вы предпочитаете использовать продукцию компании SAP и хотите организовать тестирование и автоматизировать его, я лично рекомендую вам SAP Solution Manager, но вы также можете использовать и Quality Center. Есть у нас адаптер, который позволяет объединить Quality Center и наше решение, все возможно. Так что это зависит от вашей ситуации. В SAP Solution Manager существует две лицензии – Quick Test Professional, и вторая лицензия, которая тоже является бесплатной. Клиенты в гетерогенной среде могут использовать Quick Test Professional. Так что не обязательно использовать решения от SAP.