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

«Игровой ролик: SAP для Retail»
Александр Дублин:
Суть ролика: если хотите спать в рабочее время, унижать подчиненных, то с решением от SAP вам это будет удобно. Сценарий ролика - продолжения истории: top-lap.livejournal.com/502664.html
«Пейзаж после битвы»
Александр Горбульский:
Часто интегратора выбирают по наличию опыта проектов в том бизнесе, который ведет заказчик.  Отзывы об успешности проекта часто исходят от ПМ клиента - лица заинтересованного, а вот...
«Ко­мпле­ксное решение для эле­ктро­нно­го до­ку­ме­нто­о­бо­ро­та на базе SAP ERP»
Иван Савчук:
Не хватает технической части. В остальном все очень подробно.

Мероприятия

Академия передовых практик внедрения и поддержки SAP (2014-2015) Дата проведения: 9 октября 2014 г. Все мероприятия

Глубокое погружение: плавный переход от фазы внедрения в продуктивный режим

Предыдущая Следующая

Для скачивания материала, необходимо войти на сайт или зарегистрироваться.

Глубокое погружение: плавный переход от фазы внедрения в продуктивный режим

Докладчик: Маркус-Александр Функе, Екатерина Дмитриева, SAP

У SAP существует платформа для поддержки проектов, это очень мощный инструмент, и он эффективен, даже если не все его функциональные возможности используются. Но есть вещи, которые мы рекомендуем вам использовать, и одна из них — Solution Documentation, документация решений. Когда мы говорим про управление жизненным циклом приложений, помните, что Solution Manager является ILM-платформой. То есть он с функцией IT Service Management, а также с поддержкой реализации проектов и операций. Solution Manager никогда не рассматривался как лицензируемый продукт, как продукт для продажи. Он никогда не выходил в «волшебный квадрант» бизнес-аналитиков, и поэтому многие компании к нему не прибегали.

Сегодня этот подход изменился. Мы гордимся тем, что SAP рассматривается, как лидер рынка, как HP, как IBM со своими инструментами, и что такое отношение к компании проявляется именно у опытных участников рынка, знакомых с разными решениями. Но SAP Solution Manager — по‑прежнему нелицензируемый продукт, и важно понимать, как его использовать. До конца прошлого года компания SAP использовала Solution Manager для инцидент-менеджмента с определенными ограничениями в контрактах.

Если вы используете в IT-организации это решение, у вас должен быть хелп-деск, служба поддержки, которая поддерживает все: принтеры, мобильные телефоны, все, что угодно. И обычно тут дополнительная лицензия и требовалась. Для того, чтобы улучшить использование этого решения, за которое вы платите деньги, мы убрали эти ограничения. Лишь только в некоторых ситуациях они встречаются, и там нужно приобретать дополнительные CRM-лицензии для хелп-деска. Но в 89 % случаев вы в настоящий момент можете Solution Manager использовать даже для управления не SAP-решениями. Это позволит его использовать более широко.

Ранее, в 2011‑2012 годах, многие клиенты, особенно на англо-американском рынке, не рассматривали Solution Manager как инструмент управления жизненным циклом приложений, потому что он не был сертифицирован. В 2011 году Solution Manager стал первым инструментом, который был сертифицирован по 15 ITIL-процессам.

За два года мы были единственным вендором с платформой, достигшей таких показателей. Процессы, которые верифицированы по ITIL — Service Catalog Management, Service Level Management и, конечно же, управление инцидентами. Есть некоторые дополнительные процессы, стандарты, которые можно использовать и адаптировать, но пока они формально не сертифицированы. Их можно использовать в Solution Manager, но пока что мы не получили, например, сертификацию от Pink Elephant. Эти нюансы помогут вам представить себе нашу ITIL-платформу несколько в ином свете.

Самая большая сложность состоит именно в том, что в свое время помогло компании SAP пройти путь от мейнфрейм-систем к нынешнему портфелю своих решений. Один из ключевых факторов движения заключался в том, что мейнфреймы развивались с 70‑х годов и не были задокументированы. Когда в конце 80‑х и в начале 90‑х годов в Западной Европе и Северной Америке начались крупные проекты, мы не представляли себе, что мы спроектировали, какие мейнфрейм-системы были в наличии. У каждого партнера тогда была своя собственная методология, свой собственный способ документирования процессов. Если вы обращались, например, к пяти компаниям за внедрением, вам предлагалось пять партнеров по внедрению и пять различных типов документирования процессов, и все это не находилось в базах данных. Если клиент хотел документировать проект и создаваемое решение, это делалось в Visio или в других документах устаревшего формата.

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

Как вы знаете, документирование является основным фактором улучшения и упрощения ведения бизнеса. Оно способствует синхронизации сферы IT и обеспечению прозрачности, ускорению реализации активностей и упрощению реализации активностей. Целевые группы и лица, заинтересованные в создании качественной документации, могут находиться не только в IT-департаменте, но и в других функциональных подразделениях компании. Когда мы говорим о создании Blueprint, соответственно, участники данного мероприятия — это и project-менеджер, и бизнес-эксперты, и консультанты. Все вносят свой вклад в создание Blueprint, в описание бизнес-процессов. Соответственно, для данной активности нам необходимо иметь единую точку для достоверной информации.

Что мы можем сделать при помощи Solution Manager? С чего мы начинаем? С создания проекта и с описания его атрибутов: какая методология, какие стандарты будут использоваться в проекте, какой статус проекта, дата начала, дата окончания и так далее. Project-менеджер описывает объем данного проекта, затем в работу включаются бизнес-эксперты, которые уже занимаются описанием бизнес-процессов как таковым.

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

Из чего состоит документирование нашего решения?

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

2. бизнес-процессы как таковые.

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

С точки зрения содержания, какую информацию мы можем сохранить и описать для наших процессов? Есть уровень логического компонента, то есть системная составляющая. Есть транзакция, есть так называемый тибом — те технические объекты, которые используются при запуске транзакции: например, поля, таблицы, если происходит обращение к ним. Это конфигурационный объект, если, например, нам необходимо произвести настройку в SPRO, в «Customizing». Это может быть дополнительная разработка клиентского кода. Также очень важно прописать в каждом шаге тест-кейсы: документы и информацию, которая в дальнейшем будет использоваться для тестирования. Таким образом, уже при создании Blueprint мы можем подготовить базу для разработки и проведения тестов.

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

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

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

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

В зависимости от структуры, которую вы выбираете, существует несколько видов вспомогательного инструментария для документирования. Например, в случае end-to-end процессов мы можем использовать загрузку файла. Второй вариант, мы можем осуществить интеграцию Solution Manager с «Айрис» или с другим инструментом для моделирования бизнес-процессов — таких, как PowerDesigner, и загружать информацию оттуда. Если вы используете HP Quality Center, мы можем перенести структуру из Quality Center в Solution Manager и использовать ее как базу для документирования процессов. И также всегда остается опция для ручного документирования. В случае модульной архитектуры можно воспользоваться преднастроенным репозиторием от SAP бизнес-процессов и построить свои процессы, согласно этому репозиторию.

Соответственно, давайте рассмотрим один из вариантов создания структуры решения, это загрузка через файл. Я хочу рассмотреть с вами этот пример, дабы показать, что действия с Solution Manager простые, легкие и, на самом деле, не вызывают никаких трудностей. Из чего будет состоять данная активность? Прежде всего, необходимо задать структуру. Для этого мы заходим в Solution Manager и загружаем локально файл со структурой Blueprint. Далее мы изменяем файл так, как нам нужно: можем прописать информацию для закладок, для шагов и так далее. Впоследствии, когда файл уже изменен, мы его просто загружаем в Solution Manager, и на выходе у нас в Solution Manager готовое решение. Если мы посмотрим по схеме и определим участников данного процесса, то работу с файлом может выполнять эксперт по бизнес-процессам: он создает структуру, изменяет и загружает файл, может выбрать готовое решение в Solution Manager. Файл, загруженный в Solution Manager, содержит информацию о том, какие шаги представлены, какие сценарии, информацию по каждому шагу. Можно файл изменять, добавлять информацию по документам для каждого шага — это несложные действия, специального IT-образования для этого не требуется.

Что происходит после того, как решение создано, процессы задокументированы, внедрение завершено и передано в опытную эксплуатацию. Через какое‑то время ваши бизнес-процессы изменяются, вы создаете новые отчеты, новые транзакции, может быть, меняете входные данные для текущих транзакций. Соответственно, через какое‑то время ваше решение меняется. Как узнать, насколько релевантно и актуально текущему состоянию то, что задокументировано в Solution Manager? Насколько можно положиться на данные, которые там содержатся?

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

Что такое тибомы (TBOM)? Давайте посмотрим, например, на транзакцию создания Purchase Order. У нас есть экран системы, в котором шапка и строчки документа. Мы заполняем поле вендора, балансовой единицы и так далее, поля по товарам, которые хотим закупить. Сами поля — это технические объекты, которые используются в транзакции. В каких‑то организациях, например, используется 10 полей для создания данного документа, в каких‑то организациях используется 20 полей. В дополнение к этому, при создании документа у компании могут быть настроены какие‑то дополнительные проверки, например, в связи с лимитами: если стоимость документа выше определенной суммы, необходимо вызывать в системе какие‑либо дополнительные функции. Соответственно, в фоновом режиме система обращается к тем или иным настройкам, проверочным данным, к различным таблицам. Эта информация также привязана к данной транзакции. Так вот, тибом — это совокупность тех технических объектов, которые используются в этой транзакции.

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

Виды тибомов: статистические, динамические и полудинамические. Возвращаясь к транзакции создания PO, это все технические объекты, которые используются в данной транзакции. Независимо от того, используется ли в вашей организации поле «Дополнительная информация» либо поле «Комментарий», оно все равно будет добавлено в статистический тибом.

Соответственно, у нас будет полная информация по всем объектам, но туда попадут и объекты, которые по факту не используются.

Второй вариант — динамические тибомы: в них видны именно те объекты, которые пользователь затрагивает для выполнения той или иной задачи. Например, закупщик заполнил 3 поля из 10 доступных — именно эти 3 поля будут отображаться в динамических тибомах. В чем минус динамических тибомов? Существуют транзакции — например, финансовые, варианты которых запускаются только раз в полгода или год. Соответственно, могут быть ситуации, когда не все технические объекты попадают в нашу систему. Для динамических тибомов один из моментов, когда можно актуализировать информацию — проведение ручного тестирования: мы включаем запись тибома, и у нас появляется актуальная информация в системе.

Золотая середина — это полудинамические тибомы. Они строятся при помощи следующего инструментария. В системе мы включаем некий механизм, которые собирает статистику по тем объектам, которые действительно затрагивались системой. Соответственно, имеет смысл включать этот механизм не на неделю, не на две, а, например, на месяц-два-три, чтобы данные были более или менее актуальные. Используя эту статистику, система определяет, что помимо объекта А, В, С, D еще необходимо добавить дополнительные объекты, потому что они действительно используются пользователем. К сожалению, моментально использовать и создать данные тибомы невозможно, потому что сначала необходимо собрать некоторые данные, некоторую статистику из системы.