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

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

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

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

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

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

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

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

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

1. люди (people),
2. процессы (process),
3. место (place),
4. лидерство (руководство) (leadership),
5. технологии (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. Модель программного обеспечения

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

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

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

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

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