SAP разработал и представил жизненный цикл инноваций, - от генерации новых бизнес-идей до разработки и предоставления решений. Этот подход ориентирован на человека и состоит из пяти этапов.
Explore. Исследование. Определение наиболее значимых бизнес-вызовов и наиболее ценных бизнес решений. Участвуют "лидеры бизнеса" и ИТ.
Discover. Открытие. Цель этапа «Открытие» — формирование глубокого представления о проблемах, которые необходимо решить. Для этого используются методы наблюдения, интервью и исследование рынка. Здесь вы найдете различные ресурсы, которые помогут вам пройти этот этап.
Design. Проектирование. Целью этапа проектирования является выявление лучших идей и решений, разработку прототипов, которые могут быть проверены конечными пользователями и другими заинтересованными сторонами. На этом этапе определяются компоненты архитектуры предприятия.
Deliver. Поставка решений. Разработка архитектуры решения создающих ценность (добавленную стоимость) для бизнеса и для конечных пользователей. SAP предлагает программную платформу - SAP Business Technology Platform. Конечно, это не исключает других платформ, но сайт то SAP, и этим определяется выбор платформы для поставки решения.
Run & Scale. Запуск и масштабирование решений в компании.
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. Контекстная диаграмма решения
Цель построения контекстной диаграммы решения состоит в том, чтобы предоставить высокоуровневый обзор разработанного решения форме, понятной бизнесу. На контекстной диаграмме описываются бизнес-возможности, которые должны быть удовлетворены на архитектурном уровне.
Предпосылки для создания контекстной диаграммы - матрица заинтересованных сторон и заявление об архитектурной работы. В частности, контекстаная диаграмма дает визуальное представление архитектуры заинтересованным сторонам, показывая, как решение взаимодействует с различными организационными единицами, ролями и бизнес-функциями.
Примерный вид контекстный диаграммы.
Комментариев нет:
Отправить комментарий