Показаны сообщения с ярлыком SAP. Показать все сообщения

вторник, 21 июля 2026 г.

Угроза ИИ для вендоров ERP систем

Почему акции SAP упали более чем на 3%, хотя сама SAP не публиковала никаких плохих новостей? Причина кроется в «эффекте заразы» после финансового отчета главного конкурента — компании Oracle.

Главный триггер: Шок от капитальных затрат (Capex) Oracle

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

• Капитальные затраты (Capex) Oracle в 2026 финансовом году подскочили на 162% до $55,7 млрд.

• На 2027 финансовый год Oracle планирует потратить на ИИ-инфраструктуру до $95 млрд, что почти в полтора раза выше прогнозов аналитиков ($67,7 млрд).

• Из-за этих колоссальных вливаний в дата-центры Oracle зафиксировала отрицательный свободный денежный поток (Free Cash Flow) в размере -$23,7 млрд и предупредила о неизбежном снижении валовой маржи в ближайшем году.

Парадокс: Спрос на ИИ огромен, но пугает цена входа

Важно понимать, что у Oracle нет проблем со спросом. Их облачная выручка выросла на 47% до рекордных $9,9 млрд, а выручка от Oracle Cloud Infrastructure (OCI) подскочила на 93%. Бэклог контрактов (RPO) достиг $638 млрд. Однако инвесторов пугает именно цена этого роста. Рынок начал переоценивать устойчивость денежных потоков всего сектора корпоративного софта, опасаясь, что бесконечная «гонка вооружений» за ИИ съест всю прибыль.

Эффект домино для SAP: Почему падают «чужие» акции?

Почему акции SAP упали, если SAP не объявляла о таких тратах?

• Конкурентное давление: Oracle и SAP пересекаются в сегментах ERP, облачных сервисов, баз данных и бизнес-приложений. Инвесторы рассуждают так: если Oracle тратит $95 млрд на ИИ-инфраструктуру, то SAP и другим вендорам придется тратить несоразмерно много, просто чтобы удержать долю рынка и не отстать в технологической гонке.

• Сжатие маржи: Рынок закладывает в котировки SAP риск того, что ей тоже придется резко увеличить Capex, что неизбежно ударит по ее традиционно высокой рентабельности. SAP стала «чистым и ликвидным прокси» для шорта всего сектора корпоративного софта.

Две экзистенциальные угрозы для традиционного Enterprise-софта

Аналитики выделяют два главных страха, которые сейчас давят на акции SAP и ей подобных:

• Финансовая ловушка ИИ: Спрос на ИИ-мощности реален, но стоимость инфраструктуры растет быстрее, чем доходы от нее. Если Oracle преуспеет, конкурентам придется тратить больше. Если не преуспеет — инвесторы перестанут верить в окупаемость ИИ для всего софтверного сектора.

• Угроза бизнес-модели: ИИ-инструменты становятся настолько мощными, что начинают автоматизировать задачи, для управления которыми традиционные ERP-системы (включая SAP) и были созданы. Это заставляет рынок нервничать по поводу долгосрочной экономики традиционного корпоративного софта.

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

Для клиентов и партнеров SAP это означает две важные вещи:

Давление на ценообразование: Чтобы окупить эти затраты и не разрушить свою маржинальность, SAP будет вынуждена очень агрессивно и тщательно монетизировать свои ИИ-инновации (о чем мы говорили в предыдущей статье про отказ от токенов в пользу «AI Units»).

Новые KPI для вендоров: Рынок теперь будет беспощадно оценивать любые ERP-компании не только по росту облачной выручки, но и по их способности генерировать свободный денежный поток на фоне гигантских ИИ-инвестиций. Любая ERP-система, которая не сможет доказать прямую финансовую отдачу от ИИ (как в случае с Joule), столкнется с оттоком клиентов и падением акций.

Из Телеграмм-канала "SAPLAND: Новости экосистемы"

среда, 3 августа 2022 г.

SAP инструментарий инвестиций. Deliver

SAP разработал и представил жизненный цикл инноваций, - от генерации новых бизнес-идей до разработки и предоставления решений. Этот подход ориентирован на человека и состоит из пяти этапов.

Explore. Исследование. Определение наиболее значимых бизнес-вызовов и наиболее ценных бизнес решений. Участвуют "лидеры бизнеса" и ИТ.

Discover. Открытие. Цель этапа «Открытие» — формирование глубокого представления о проблемах, которые необходимо решить. Для этого используются методы наблюдения, интервью и исследование рынка. Здесь вы найдете различные ресурсы, которые помогут вам пройти этот этап.

Design. Проектирование. Целью этапа проектирования является выявление лучших идей и решений, разработку прототипов, которые могут быть проверены конечными пользователями и другими заинтересованными сторонами. На этом этапе определяются компоненты архитектуры предприятия.

Deliver. Поставка решений. Разработка архитектуры решения создающих ценность (добавленную стоимость) для бизнеса и для конечных пользователей. SAP предлагает программную платформу - SAP Business Technology Platform. Конечно, это не исключает других платформ, но сайт то SAP, и этим определяется выбор платформы для поставки решения.

Run & Scale. Запуск и масштабирование решений в компании.

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

люди (people),
процессы (process),
место (place),
лидерство (руководство) (leadership),
технологии (technology).

Этап - Поставка решений (deliver)

На этапе поставки готовятся технические решения развертывания решения продуктивного использования. В конце этапа создается рабочая версия решения для развертывания в качестве пилотного проекта.

Шаг 1. Среда выполнения и диаграмма развертывания

Показывается географии расположения строительных блоков и сведения о среде выполнения.

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

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

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

Пример диаграммы развертывания

Шаблон диаграммы развертывания

Шаг 2. Дорожная карта реализации архитектуры

Описание действий, необходимых для реализации архитектуры.

Исходные данные для создания дорожной карты архитектуры — это сочетание всех идей, сгенерированных на предыдущих этапах. Хорошим началом является диаграмма реализации решения.

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

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

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

Пример дорожной карты:

Шаблон дорожной карты:

суббота, 30 июля 2022 г.

SAP инструментарий инвестиций. Design

люди (people),
процессы (process),
место (place),
лидерство (руководство) (leadership),
технологии (technology).

Этап - Проектирование (design)

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

Результаты этапа:

Анализ идей и выбор лучших для прототипирования.
Создание прототипа для демонстрации работоспособности идеи.
Разработка целевой технической архитектуры предлагаемого решения с учетом мнений заинтересованных сторон.
Получение отзывов о предлагаемых решениях.

Шаг 1. Формирование идей

Генерация идей структурированным и творческим способом.

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

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

Успешная сессия требует открытого мышления, готового приветствовать любые идеи, как "реальные" так и "нереальные". Позже будет время решить и оценить, а пока нужно воспринимать каждую идею как возможность.

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

Прежде чем приступить к сеансу, возможно стоит ознакомить участников со следующиеми правилами:

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

Шаг 2. Идея "на салфетке"

Краткое описание идей, буквально - на салфетке, полученных в ходе мозгового штурма. Расстановка идей по приоритетам.

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

Держите рядом с собой стикеры с выбранными идеями. Начните с того, что дайте идеям имя и краткое описание.
Создайте грубый набросок, отражающий суть идеи.
Укажите, кому будет полезна идея, и перечислите все возможные группы пользователей. Затем опишите ценность каждой идеи с точки зрения разных целевых групп. Используйте разные цвета для каждой группы пользователей.
Опишите все аспекты, которые делают идею уникальной или инновационной по сравнению с другими, подобными существующими решениями.
Оцените идею по шкале от 1 до 10 с разных точек зрения: ценность для бизнеса, устойчивость, инновационный потенциал и ценность для пользователей. Суммируйте все оценки, чтобы получить общий балл. Этот балл можно использовать для определения приоритета идей.

"Салфетка идей" примерно может выглядеть так:

Шаг 3. Руководство по созданию прототипа

Создание модели, которая делает идею осязаемой и готовой к проверке.

Зачем делать прототип?

После того, как идеи были сгенерированы, необходимо их протестировать, показать заинтересованным сторонам и конечным пользователям. Это позволяет убедиться в правильности выбранного направления.

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

Когда прототипировать?

Создание прототипов обычно происходит на этапе проектирования. И прототипирование итеративно: первоначальные прототипы улучшаются на основе собранных отзывов до тех пор, пока команда не будет удовлетворена решением.

Уровень детализации прототипа.

Выделяют горизонтальное или вертикальное прототипирование.

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

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

Показывайте даже незавершенные прототипы. Цель прототипирования — протестировать идеи с тем, чтобы избежать серьезных изменений во время проектирования или реализации идеи. Затраты и время на прототипирование значительно меньше затрат на создание реального решения.

Шаг 4. Раскадровка видения

Создание наглядного рассказа об использовании решения.

Зачем создавать раскадровку видения?

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

Когда создавать раскадровку видения?

Раскадровка видения используется на этапе проектирования для определения будущего сценария и создания прототипа, демонстрирующего работу идеи.

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

Пример раскадровки видения:

Шаг 5. Обратная связь

Получение обратной связи от пользователей, заинтересованных сторон, экспертов. Структуризация полученных отзывов.

Отзывы группируются в таблице отзывов со следующими колонками:

Что было воспринято положительно.
Какие проблемы возникли в ходе презентации прототипа.
Какие возникли новые идеи.
Какие вопросы возникли по ходу презентации.

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

Для получения значимых отзывов стоит заранее определить вопросы к прототипу, определяющие - что нужно узнать о прототипе у пользователей.

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

Пример структуризации отзывов:

Шаг 6. Презентация инвестору

Представление для утверждения решения руководству и ключевым заинтересованным сторонам.

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

Можно предложить оформить текущее решение на одном слайде, указав:

Заказчик решения.
Необходимость решения.
Само решение.
Рыночный сегмент.
Ключевое преимущество решения.
Конкурентная ситуация.
Уникальный отличительный признак решения.

Шаг 7. Вариант использования - диаграмма Use-Case Blueprint

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

Цель схемы вариантов использования — перейти от проектного мышления к архитектурному мышлению. Действия, ориентированные на пользователя, сопоставляются с техническими аспектами архитектуры, такими как данные, системы и технические возможности. Диаграмма Use-Case Blueprint ориентирована на пользователя и является мостом к творческому мышлению и методологии дизайн-мышления.

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

Раскадровка создается для указания - как персонаж взаимодействует с целевым решением. После создания раскадровки разные сцены помещаются на лист горизонтально одна за другой. Под каждой сценой подписываются действия, выполняемые персонажем. Для каждого персонажа могут использоваться разные цвета с указанием имени персонажа для каждого действия. Далее указываются требуемые данные, приложения, технические требования и возможности (например, прием данных IoT, чат-бот или сервис рабочего процесса), которые необходимы для реализации действий пользователя.

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

Пример диаграммы.

Шаг 8. Базовая архитектура решения

Описание существующих приложений и ИТ-компонент, соответствующие варианту использования.

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

Требуемые операции:

Список всех текущих приложение и ИТ компонент для повторного использования.
Понимание зависимостей между идентифицированными ИТ компонентами (функциональная зависимость в терминах запрос/ответ и в терминах информационных потоков).
Список пользователей и ролей, взаимодействующих с ИТ компонентами.

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

Пример презентации базовой архитектуры решения:

Шаг 9. Концептуальная схема решения

Создание высокоуровневого представления предлагаемого решения.

Концептуальная схема решения есть путь перехода от контекста решения к диаграмме реализации решения. По сути дела - это карандашный набросок решения, которое связывает строительные блоки для реализации решения.

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

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

Пример концептуальной схемы решения.

Шаблон концептуальной схемы решения.

Шаг 10. Диаграмма реализации решения

Техническое описание предполагаемого решения с помощью строительных блоков решения.

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

Технология построения диаграммы:

Определение строительных блоков решения, которые реализуют ранее идентифицированные строительные блоки архитектуры.
Сопоставление строительных блоков архитектуры с одним или несколькими строительными блоками решения.
Источником разработки строительных блоков решения являются базовая архитектура решения и информация конкретного поставщика (функциональные зависимости запрос/ответ или информационный поток).
Добавление пользователей и ролей к строительным блокам решения.
Проверка диаграммы реализации решения на полноту.

Пример диаграммы реализации реализации:

Шаблон диаграммы реализации решения:

Шаг 11. Список архитектурных решений

Документирование архитектурных решений и рассуждений.

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

Для документирования строится таблица с колонками:

Идентификатор.
Решение.
Причина выбора (обоснование).

Шаг 12. Концептуальная модель данных

Описание информационных объектов.

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

Информационные объекты (сущности), обрабатываемые строительными блоками решения, наносятся на диаграмму. Информационные объекты идентифицируются однозначным именем, для них добавляются атрибуты или свойства с соответствующими типами данных. Типы данных - простые, например, «число», «строка», «дата». Информационные объекты связываются отношениями. Для отношений указывается множественность. Разные типы отношений отображаются по разному. Например, ассоциация представляется сплошной линией между двумя объектами и описывается глаголом.

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

Пример концептуальной модели данных:

Шаг 13. Модель программного обеспечения

Модель показывает, как архитектура и строительные блоки решения распределяются по ИТ-инфраструктуре.

Цель модели - дать представление о том, как развертывается решение, а именно определяется среда размещения и развертывания программного обеспечения в разрезе строительных блоков решения.

Поскольку корпоративная ИТ-инфраструктура обычно выходит за пределы четырех стен корпоративного центра обработки данных, цель модели программного обеспечения - показать, в каких «посадочных зонах» работают различные строительные блоки архитектуры.

Пример модели программного обеспечения:

Шаблон модели программного обеспечения:

четверг, 7 июля 2022 г.

SAP инструментарий инвестиций. Discovery

SAP на сайте https://apphaus.sap.com/toolkit опубликовал широкий спектр инструментов поддержки реализации инноваций - Innovation Toolkit. Эти инструменты, по замыслу SAP, позволяют организовывать, масштабировать и реализовывать инновации в организациях.
SAP разработал и представил жизненный цикл инноваций, - от генерации новых бизнес-идей до разработки и предоставления решений. Этот подход ориентирован на человека и состоит из пяти этапов.

люди (people),
процессы (process),
место (place),
лидерство (руководство) (leadership),
технологии (technology).

Описание ЭТАПа - "Раскрытие" - Discovery

Как только на этапе "Исследование" определены проблемы и проекты, необходимо перейти к более тщательному их рассмотрению и конкретизировать основные области проекта и определить конкретные требования. Этому посвящены работы этапа "Раскрытие". Возможно также переводить "discovery" как исследование.

Результатом работ этапа "раскрытие" являются:

Понимание бизнес-проблем с позиции конечного пользователя.
Генерация дизайн-идей решения.
Формирование представления о архитектурном ландшафте и сопоставление его с вариантами решений.
Формирование фундамента для разработки технических аспектов решения..

Шаг 1. Контекстная карта

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

Контекстная карта помогает членам команды понять, что влияет на проект, определить границы проекта, уточнить объем и направленность проектов.

Контекстная карта оформляется в виде цветка с лепестками. В центре записывается проблема, на лепестках - идеи, сформулированные в ходе мозгового штурма.

Что такое идея? В данном контексте можно предложить следующее.

Идея - это видение "будущего", создание которого направлено на удовлетворение потребностей пользователей. Идея может быть направлена на создание нового продукта, связана с улучшением текущего продукта, направлена на изменение технологии.

Идеи, например, могут быть классифицированы следующим образом:

Продуктовая идея - разработка рыночного продукта.
Цифровой продукт - создание нематериального продукта, связанного с ИТ технологиями.
Lean продукт - идея экномии ресурсов.
Функциональная идея - повышение результативности и эффективности конкретной функции.
Организационная идея - разработка или совершенствование системы управления.
Создание актива - создание или приобретение активов, материальных или нематериальных.

Шаг 2. Разработка руководства полевых исследований

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

Следует

Разработать протокол интервью. В частности, он должен содержать сведения о департаменте, о конечном пользователе, дате интервью.
Создать рабочую тетрадь с предзаполненными полями и вопросами пользователю.
Отправить пользователям рабочую тетрадь для ознакомления.
Провести интервью. Желательно, чтобы вопросы задавал один человек, а ответы записывал другой человек. Не следует во время интервью задавать наводящие вопросы или подсказывать пользователям те или иные варианты ответов, идей или решений.
Собрать сопутствующие интервью документы, файлы, таблицы или изображения.
Подвести итоги каждого интервью с членами группы.

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

Шаг 3. Синтез и визуализация информации

На данном шаге мысли, данные и соображения наносятся на доску и образуют синтетическую сеть - Synthesis Grid. В частности, это может выглядеть следующим образом:

или

Шаг 4. Персонажи

На этом шаге создаются архетипы пользователей по результатам интервью с конечными пользователями. Архетип пользователя описывается совокупностью целей (краткосрочных и долгосрочных), задач и пожеланий конечного пользователя.

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

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

Идентификационные характеристики пользователя.

Фото, имя, возраст, образование и др.

Описание пользователя в контексте решаемой задачи проектирования:

Роли пользователя.
Цели пользователя.
Решаемые задачи.
Последовательность и взаимосвязь задач (работ, функций).
Триггеры или стартовые события, запускающие задачи.
Как часто выполняются задачи.
Длительность задач (работ).

Симпатии и антипатии пользователей.

Что нравится?
Что расстраивает?

Визуализация собранной информации может проводиться, например, так.

Шаблон.

Шаг 5. Карта взаимодействия с пользователем (User Experience Jiurney Map)

На этом шаг создаются сценарии поведения и описываются мотивы пользователей.

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

На этом шаге фиксируется процесс «как есть» (as-is) с ориентацией на человека. Описание процесса «как есть» обычно происходит после проведения интервью с соответствующими группами пользователей и после сбора достаточной информации для понимания текущей ситуации.

Примечание. Чтобы создать карту взаимодействия с пользователем, вначале необходимо определить персоны, которые пройдут этот путь.

Шаблон для заполнения карты взаимодействия с пользователем.

В средней полосе записываются действия пользователя: Какие действия предпринимает пользователь, пытаясь достичь свою цель, выполнить свои задачи?

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

В ннжней полосе записываются "точки взаимодействия" пользователя: с чем взаимодействуют пользователи, какие инструменты и устройства используют, с какими людьми взаимодействуют, какие ведут разговоры.

На карте отмечаются "болевые точки" и точки типа "момент истины".

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

Пример заполненной карты взаимодействия с пользователем:

Шаг 6. Постановка задачи

Решаемая проблема формулируется как изложение возможностей решения проблемы на этапе проектирования. Тем самым создается постановка задачи. Постановка задачи позволяет генерировать идеи на этапе проектирования. Основной вопрос в ходе выработки постановки задачи: "Что мы можем?"

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

Шаг 7. Архитектурные принципы

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

Принципы архитектуры определяют ограничения, с которыми будет иметь дело архитектура.

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

В общем следует

Определить ограничения, которые необходимо принямать во внимание в ходе разработки архитектуры.
Выработать понимание преимуществ бизнеса, которым должна поддерживать разрабатываемая архитектура.
Выявить болевые точки и точки типа "момент истины".

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

Шаг 8. Анализ рисков

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

На этом щаге следует определить и кратко описать риски. Затем классифицировать их по уровням риска. Например,

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

Затем определяются действия для смягчения идентифицированных рисков. После этого пересчитывается уровень риска с учетом принятых мер и вычисляется остаточный уровень риска. Описывается влияние остаточного уровня риска на архитектуру.

Полученные результаты оформляются в табличном виде:

Шаг 9. Контекстная диаграмма решения

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

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

Примерный вид контекстный диаграммы.

пятница, 17 июня 2022 г.

SAP инструментарий инноваций

SAP на сайте https://apphaus.sap.com/toolkit опубликовал широкий спектр инструментов поддержки реализации инноваций - Innovation Toolkit. Эти инструменты, по замыслу SAP, позволяют организовывать, масштабировать и реализовывать инновации в организациях.

SAP разработал и представил жизненный цикл инноваций, - от генерации новых бизнес-идей до разработки и предоставления решений. Этот подход ориентирован на человека и состоит из пяти этапов.

люди (people),
процессы (process),
место (place),
лидерство (руководство) (leadership),
технологии (technology).

Описание ЭТАПа - Исследование - Explore

Целью этапа "Исследование" является выявление наиболее ценных бизнес-задач, на которых следует сосредоточиться бизнес- и ИТ-руководителям. В ходе этого этапа выявляются проблемы, которые предстоит решить и достигается согласованное мнение членов команды и заинтересованных лиц по данным вопросам.

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

Перечень бизнес-задач как инновационных проектов.
Описание характера поддержки корпоративной стратегии инновационными проектами.
Описание состава участников инновационного проекта.
Определение объемов инновационных работ.

Рекомендуемый путь выполнения данного этапа:

Оценка согласованности инновационных проектов с корпоративной стратегией.
Определение бизнес-задач.
Вовлечение заинтересованных лиц.
Мастерская изучения бизнес-проектов.
Создание видения.
Определение архитектуры.
План игры.

Шаг 1. Оценка согласованности инновационных проектов с корпоративной стратегией

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

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

Данный шаг предполагет следущие работы.

1.1. Краткое формулирование видения компании.

1.2. Описание бизнес-факторов и целей, определяющих текущий бизнес компании. Различные примеры описания бизнес-факторов можно найти в отраслевых технических документах SAP.

1.3. Перечисление стратегических целей компании и задач, поддерживающих стратегические цели.

Цели формулируются в соответствии с критериями SMART (конкретные, измеримые, достижимые, реализуемые и ограниченные во времени формулировки).Стратегическая цель содержит описание и примеры быстрого и эффективного использования капитала для бизнес-инициатив и проектов.

1.4. Сопоставление проектов и инициатив с целями и задачами компании

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

На сайте MURAL размещен шаблон стратегической карты, который приводится ниже.

Шаг 2. Определение бизнес-задач

На данном шаге используется анкетирование.

2.1. Фиксация основных проблем, внешних рисков, внутренних барьеров и формированию идей по решению проблем.

Данные собираются в разрезе бизнес секторов (бизнес-областей). Для этого 5-6 ключевым топ-менеджерам направляются анкеты с минимум пятью вопросами:

Рассматриваемая бизнес-область.
Перечень основных проблем или вызовов (Challenges).
Перечень внешних рисков (External Risks).
Перечень внутренних барьеров (Internal Barriers).
Идеи в части решения обозначенных бизнес-проблем (Solution Ideas).

2.2. Документирование и "визуализация" полученных ответов.

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

Пример визуализации, представленный SAP (видимо подразумевается, что рассматривается единственная бизнес-область).

2.3. Кластеризация объектов.

В фокусе рассматриваются идеи. Процесс расскрытия проводится "от результата". Ниже - пример кластеризации.

2.4. Представление бизнес-кейса.

Описывается идея решения, избегая слишком общих формулировок, таких как «повысить эффективность» или «повысить качество". Упоминаются технологии или услуги, которые позволяют достичь результатов.

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

Оценка бизнес-кейса (может быть проведена по бальной системе от 1 до 5). Используются следующие измерители.

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

Шаг 3. Вовлечение заинтересованных лиц

Формирование понимания - кто принимает решение о старте решения.

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

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

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

3.1. Выявление всех игроков в контексте проекта.

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

3.2. Размещение заинтересованные стороны на карте заинтересованных сторон.

Основные заинтересованные стороны помещаются во внутренний круг, а второстепенные - во внешний круг. Остальные размещаются снаружи.

3.3. Анализ интересов и опасений с помощью матрицы заинтересованных сторон.

Анализируя заинтересованные стороны, оцениваются их интересы и опасения в отношении проектов. Ссновные интересанты переносятся с карты в матрицу заинтересованных сторон. В столбце интересов записываются мотивы и стимулы сторон. Для проблем записываются факторы, которые мешают сторонам поддерживать проект.

3.4. Разработка стратегии вовлечения сторон в проект.

Для каждой заинтересованной стороны опеределяются способы привлечения их к проекту. Можно использовать следующую шкалу типов вовлеченности:

ключевой игрок,
удовлетворенный игрок,
информированный игрок,
минимально вовлеченный игрок.

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

Шаг 4. Мастерская изучения бизнес-проектов

Генерация идей, вариантов использования, определение наиболее перспективных путей реализации проекта.

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

К началу данной фазы должны быть:

Определены бизнес-задачи, барьеры и внешние риски.
Определены ключевые заинтересованные лица.

4.1. Организация семинара для обсуждения идей и бизнес-проектов.

Планируется семинар с заинтересованными сторонами как со стороны бизнеса, так и со стороны ИТ для обсуждения идей, которые ранее определены на шаге «Определиение бизнес-задач». На сессии должны присутствовать представители ИТ и представители бизнеса. Список участников, в частности, должен включать заинтересованных лиц, определеннных на шаге «Вовлечение заинтересованных лиц».

4.2. Проведение семинара.

Примерный ход семинара:

Тема, повестка дня и правила (8 мин). Представление участникам темы и повесткы дня сессии, а также ожидаемые результаты. Определение общих правил поведения на сессии, такие как: приходить вовремя, оставаться сосредоточенным, активно участвовать.
Представление участников (5 – 11 мин). 1 минута для самопрезентации и артикуляции своей роли и мотивации в рамках данного семинара.
Ознакомление с подходом подхода SAP к инновациям (5 мин) — необязательно.
Воодушевление участников с помощью демонстрации технологий SAP (5 мин) — необязательно.

4.3. Обсуждение проблем, задач, внешних рисков и внутренних барьеров.

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

4.4. Организация мозгового штурма.

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

Затем участники предоставляют команде свои идеи. 2 минуты для каждого участика. По итогу схожие идеи группируются.

4.5. Создание наборов (кластеров) вариантов решений.

Создаются варианты решений.

Здесь объединяются идеи с вызовами, внешними рисками и внутренними барьерами. Тем самым формироваютсь наборы вариантов решений. Каждый набор должен содержать как минимум одну идею и одну задачу. Каждому набору присваивается название.

4.6. Формулирование вариантов решения и определение их приоритетности.

После того, как сформированы наборы решений, создается описание вариантов. Например, может использоваться такая формула для описания вариантов:

Нашему [отделу] нужна [идея решения] для [конечного пользователя] с целью [улучшения/оптимизации/облегчения] решения следующей [задачи] .

Затем оценивается каждый вариант по шкале от 1 до 5 и выбераются 5 лучших вариантов решения.

4.7. Нахождение похожих вариантов решения.

Для каждого варианта решения просматриваются и записываются аналогичные варианты в SAP Discovery Center или на веб-сайте SAP Business Technology Platform.

4.8. Фиксация соответствий в вариантах решений.

Для каждого варианта решения выберается наиболее похожий вариант решения, записывается его название, заполняется следующая информация:

Метрика соответствия. Насколько близок существующий вариант использования к исследуемому варианту решения по шкале от 1 до 5. Насколько полно решается проблема. Насколько точно совпадают целевые аудитории решений.
Что нужно улучшить, добавить или уточнить. Какие аспекты не охватываются существующим вариантом.
Трудности решения. Сколько усилий потребуется для реализации варианта по шкале от 1 до 5 с учетом существующих ресурсов.
Последовательность шагов. Какие шаги нужно предпринять в краткосрочной перспективе, чтобы реализовать варианта.

Если для варианта решения соответствие не найдено, то записывается «НОВОЕ» в разделе «Подходящая идея варианта решения».

4.9. Создание дорожной карты вариантов решения.

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

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

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

Шаг 5. Создание видения

Создается видение будущего и устанавливаются вехи на этом пути. Видение должно разделяться участниками команды.

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

Примерный рисунок визуализации видения.

Шаг 6. Определение архитектуры

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

К началу данной фазы должно быть:

Проведено согласование проектов с корпоративной стратегией.
Проведено исследование вариантов решений.

6.1. Понимание архитектурных требований и бизнес-контекста.

В бэкграунде должно быть обоснование проекта и иная необходимая справочная информация касательно инновационного проекта. Отправная точка шага - обоснование соответствия решения целям компании. Для этого оцениваются бизнес-задачи, решаемые проектом. Информация о бизнес-задачах должна содержаться в описании решения, подготовленном на шаге "Шаг 4. Мастерская изучения бизнес-проектов".

Затем проверяется соответствие целей и задач проекта стратегическим целям компании. Эта информация содержится в Стратегической карте, созданной на шаге "Шаг 1. Оценка согласованности инновационных проекстов с корпоративной стратегией".

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

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

6.2. Определение масштаба архитектуры.

Кратко описывается объем архитектуры и создается общая диаграмма архитектурного решения. Описание архитектурного решения может примерно выглядеть следующим образом:

Заголовок.
Описание требований к проекту и описание контекста.
Описание масштаба проекта.
Описание архитектурного видения.
Роли, ответственность и работы.
Процедуры и критерии приемки.
Архитектурый и календарный планы.

Для формирования объема архитектуры берется информация о бизнес-задачах и целях компании. На основании этого формулируются цели и задачи архитектуры. После чего заполняется «Описание масштаба проекта» и «Описание архитектурного видения». Для подобных документов могут быть использоваться соответствующие шаблоны.

6.3. Определение критериев приемки.

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

Заполняются пункты в шаблоне:

Роли, обязанности и результаты проекта.
Критерии и процедуры приемки результатов.

Архитектурный план и расписание ссылаются на «Дорожную карту архитектуры» и могут быть созданы позже. Необязательным на данном этапе определение ролей и ответственности.

Шаг 7. План игры

План игры показывает как можно добиться желаемого в проекте. Это поможет команде:

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

На данном шаге выполняются следующие действия.

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

План игры можно визуализировать следующим образом

Следующий этап - Discover. Открытие. Здесь - не раскрывается.

понедельник, 13 июня 2022 г.

SAP инструментарий инноваций

люди (people),
процессы (process),
место (place),
лидерство (руководство) (leadership),
технологии (technology).

воскресенье, 24 января 2021 г.

Фунциональность SAP управления проектами

SAP PS "Управление проектами"

Система проектов предназначена для управления жизненным циклом проекта, начиная от структурирования и заканчивая планированием, реализацией, вплоть до завершения проекта.

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

Модуль «Управление проектами» поддерживает полный жизненный цикл проекта: от планирования до реализации и анализа результатов. Гибкая система позволяет настроить индивидуальные параметры для каждого проекта, с учетом потребностей и особенностей работы предприятия.

Функционал SAP PS включает в себя:

Планирование проекта

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

Отражение фактически проведенных работ

В системе проводится подтверждение работ, прием услуг и учитывается списание материалов на проект.

Управление проектами

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

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

Интеграция между SAP PS и прикладными модулями SAP ERP

Позволяет проектировать, планировать и выполнять проекты как часть обычной процедуры проекта. Модуль SAP PS (SAP Project System) имеет постоянный доступ к данным для всех отделов, участвующих в проекте.

Модуль «Управление проектами» интегрирован с другими модулями системы. Так, формирование платежей и контроль финансовых потоков проходят в модуле FI «Финансы», реализация проекта по заказу клиента связано с модулем «Сбыт», планирование потребности и обеспечение необходимыми материалами и услугами – с модулем «Управление материальными потоками».

Также управление проектами интегрировано с модулями

РР «Производство»,
СО «Управленческий учет»,
IM «Управление инвестициями»,
FI-AA «Учет основных средств»
HCM «Управление персоналом».

Таким образом, система SAP PS тесно интегрирована со следующими модулями:

Модуль «Финансы и контроллинг» — для планирования затрат и доходов в системе проектов в соответствии с требованиями финансового планирования. Включая интеграцию с компонентой FI_AA – учет основных средств.
Управление материальными потоками MM — для управления функциями закупок и инвентаризации, происходящими в жизненном цикле проекта.
Модуль продаж и распространения — для управления процессом продаж в жизненном цикле проекта — включает предложения для проектов клиентов. Это включает выставление счетов, продажу и доставку товаров и услуг, необходимых в жизненном цикле проекта.
Планирование производства — для выполнения таких операций, как планирование потребности в материалах, ППМ спецификации материалов, реквизиция материала в соответствии с ППМ, планирование мощности и другие задачи планирования производства в жизненном цикле проекта.

SAP PROJECT AND PORTFOLIO MANAGEMENT (SAP PPM)

SAP Project and Portfolio Management (SAP PPM) обеспечивает автоматизацию процессов управления проектами и значительно облегчает управление портфелями проектов.

Управление портфелем проектов

Ведение структуры инвестиционной программы с возможностью агрегации показателей с уровня отдельных проектов на уровень инвестиционных программ и портфелей. Допускается одновременное использование нескольких альтернативных структур (представлений) инвестиционной программы.
Поддержка процесса финансового планирования и контроля реализации проектов, инвестиционных программ, портфелей проектов. Гибкое определение состава финансовых показателей. Возможность планирования и учета натуральных показателей проекта.
Автоматизация процессов ранжирования проектов при отборе в инвестиционную программу на основе формальных показателей и экспертных оценок.
Поддержка процессов управления на уровне группы проектов.
Поддержка гейтовой модели жизненного цикла проекта. Планирование фаз и точек принятия решения. Гибкое определение условий смены фазы. Внесение в систему решения о завершении фазы с возможностью использования ЭЦП. Поддержка различных жизненных циклов, в зависимости от типа проекта.
Автоматизация согласованного процесса управления изменениями на уровне инвестиционной программы.

Управление отдельными проектами

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

Управление проектными ресурсами

Планирование ролевой структуры проекта и ролевых трудозатрат по задачам.
Назначение сотрудников на роли с учетом их квалификации и загрузки.
Возможность делегирования полномочий по назначению сотрудников на проектные роли руководителям ресурсных пулов. Возможность внесения кандидатов на проектные роли.
Учет фактических трудозатрат и процента фактического исполнения работ в разрезе проектных ролей и задач.
Анализ загруженности ресурсов.

Работа с проектными документами

Формирование структуры папок документов для всех уровней управления (программы/ подпрограммы/объекта).
Регистрация статуса документа.
Хранение документов в привязке к основным объектам управления системы, в том числе к проектам, фазам, задачам.
Совместная работа с документами с возможностью организации доступа внешних контрагентов. Управление процессом согласования документов в системе, настраиваемые статусные схемы согласования.
Возможность хранения и просмотра предыдущих версий документов.
Ведение библиотеки шаблонов документов.
Поддержка гейтовой модели работы с проектами: определение типового набора фаз и точек принятия решения для различных типов проектов.
Контроль прохождения фаз жизненного цикла, определение условий перехода на следующую фазу.
Поддержка процесса согласования при прохождении точки принятия решения.

Интеграционные возможности

Интеграция с внешними системами календарно-сетевого планирования (Microsoft Project, Oracle Primavera).
Возможность осуществления привязки к проекту SAP PPM, а также его фазам и отдельным задачам объектов системы SAP ERP (определения проекта PS, СПП-элементы, заголовки и элементы сетевого графика, заказы и позиции заказов на закупку MM, внутренние заказы CO и другие). Данные связанных объектов SAP ERP доступны для анализа и контроля в функциональности аналитических отчетов SAP PPM (с возможностью оповещения ответственных лиц об отклонениях).
Возможность автоматического формирования структуры проекта PS на основании структуры проекта SAP Project and Portfolio Management (SAP PPM);
Возможность загрузки в Project and Portfolio Management (SAP PPM) плановых и фактических затрат по проекту из данных по связанным объектам затрат SAP ERP (СПП-элементы, внутренние заказы).
Возможность загрузки справочника ресурсов из SAP HCM.
Возможность автоматического формирования в SAP Project and Portfolio Management плана трудозатрат по группам ресурсов на основании данных CO Activity Input Planning.
Возможность регистрации фактических трудозатрат по задачам проектов PPM в модуле SAP ERP CATS.
Возможность перехода в транзакции SAP ERP для детального анализа.

четверг, 16 июля 2020 г.

Design Thinking

SAP развивает специальный инструментарий разработки приложений - design thinking. Полезным инструментом и одновременно простым является подход определения потребностей пользователей, а уже исходя из этого формировать требования к приложению.
Этот поход не является очень новым материалом. В тех или иных вариациях подобный подход находит свое применение под разными названиями. Например, под названием "user story".

Удобство же состоит в следующем

Материал структурирован.
Вся информация размещена на одной странице.
Вся информация излагается кратко и понятно.

Документ с описанием пользователя - "persona". В частности, вот пример persona list, используемый в презентационных материалах SAP.

Структура документа следующая.

Девиз пользователя
ФИО и фото пользователя.
Должность и главная функция (за что отвечает) пользователя.
ABOUT - "краткие данные о пользователе".
Главные цели.
Должностные обязанности.
WORKS WITH - "с кем работает/контактирует".
Потребности.
PAIN POINTS - "болевые точки" (другими словами, проблемные вопросы).
Компетенции.

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

Перечень компетенций:

Опытный пользователь (power user) / Случайный пользователь (casual user).
Дальновидный (proactive) / пассивный (reactive) пользователь.
Командный игрок / пользователь-одиночка.
Глобальный / локальный взгляд (фокус).
Инновационный / консервативный подход.

Еще один пример "persona".

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

В части задач пользователя стоит упомянуть о классификации задач:

вторник, 21 июля 2026 г.

среда, 3 августа 2022 г.