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

В данном докладе мы рассмотрим основные аспекты процесса, который называется «Управление жизненным циклом приложения» (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 вы определяете организационное подразделение — например, группу по продажам, которая вовлечена в эти процессы, потом определяете мастер-данные (например, продуктовый каталог, условия ценообразования, маркетинг и так далее). Это необходимые показатели, которые сюда включены.

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

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

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

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

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

Материалы для скачивания

Робин Шонвальд, Уменьшаем риски за счет эффективного управления тестированием (EN)Day2_15h15_Robin.pdf