Decision-making: управление проектами

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

среда, 18 июня 2025 г.

Что можно сделать в управление проектами ИТ

В основе успешных инициатив лежит часто недооцененный, но критически важный компонент: Офис управления проектами (PMO).

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

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

Человеческий фактор в управлении проектами

Переход от технологически-ориентированных подходов к человеко-ориентированным

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

Гуманный подход к трансформации ставит во главу угла:

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

Принятие решений на основе данных: необходимое дополнение

Хотя человеческий фактор является основным, данные - это компас, который указывает направление усилий по трансформации. Данные используются для:

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

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

Современный офис управления проектами (PMO) - стратегический партнер в трансформации бизнеса

Переосмысление роли и ценностного предложения PMO

PMO функции как стратегического партнера в трансформации бизнеса:

Business Value Orchestrator: обеспечение того, чтобы технические реализации трансформировались в измеримые бизнес-результаты.
Transformation Facilitator: руководство организацией в ходе сложных изменений.
Cross-Function Connector: разрушение разрозненности между ИТ- и бизнес-подразделениями. Innovation Catalyst: выявление возможностей использования возможностей программного обеспечения для получения конкурентного преимущества.
Knowledge Hub: формирование институциональной экспертизы, способствующей самодостаточности.

Ключевые функции современного PMO

Объем обязанностей PMO продолжает расширяться в связи с растущей сложностью решений и ускорением темпов бизнес-изменений:

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

Критические факторы успеха PMO, ориентированных на человеческие ресурсы и данные

Спонсорство руководства и управление, ориентированное на человека

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

Структура управления, ориентированная на человека, обычно включает в себя:

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

Интегрированное управление изменениями

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

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

Управление ресурсами на основе данных

В новой норме управления проектами управление ресурсами выходит за рамки электронных таблиц и целевых показателей использования:

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

Постоянное обучение и совершенствование

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

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

Распространенные проблемы при трансформации и человеко-ориентированный подход

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

Согласование заинтересованных сторон и управление ожиданиями

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

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

Техническая сложность и интеграция

Технические аспекты внедрения ПО представляют собой уникальные проблемы, для решения которых необходим комплексный подход, основанный на анализе человека и данных:

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

Баланс скорости и качества с учетом человеческих ограничений

В современной быстро меняющейся бизнес-среде офисы проектов внедрения ПО сталкиваются с постоянным давлением, связанным с необходимостью ускорения сроков внедрения:

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

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

Интеграция ориентированного на человека лидерства с мощной аналитикой данных представляет собой передовую линию эволюции PMO.

Комплексная экосистема панели мониторинга, ориентированная на человека

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

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

Расширенная аналитика для принятия обоснованных решений

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

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

Инструменты для совместной работы, улучшающие взаимодействие людей

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

Обзор согласований и утверждений: заинтересованные стороны проекта получают видимость родительских и дочерних подписей через интуитивно понятное пирамидальное представление. Эта ясность относительно статуса утверждения и обязанностей заинтересованных сторон оптимизирует принятие решений, обеспечивая при этом надлежащее распределение ответственности.
Автоматически генерируемые отчеты: автоматическая генерация отчеты о встречах, отслеживание CTA, отчеты о проблемах и полную документацию по рабочим элементам. Эта автоматизация снижает административную нагрузку, одновременно повышая прозрачность коммуникации — ключевой аспект управления проектами, ориентированного на человека.
Аналитика событий: руководители PMO и ИТ-директора получают видимость деталей сеансов и процентов посещаемости, максимизируя влияние событий проекта и обеспечивая эффективное использование совместного времени. Хорошо организованные встречи создают ценность, а не потребляют ее.
Группы портфелей: настраиваемые представления портфелей, которые способствуют бесперебойному сотрудничеству между всеми ролями проекта, сохраняя стратегическое соответствие для заинтересованных сторон-исполнителей. Эта гибкость позволяет командам организовывать информацию способами, которые наилучшим образом соответствуют их конкретным потребностям и стилям работы.

Трансформирующее влияние возможностей PMO

Ключевые способы трансформации возможностей PMO:

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

Реальное воздействие: гуманная трансформация на основе данных в действии

Возможные улучшения:

Ускоренное время окупаемости: сроки внедрения сокращены на 20–30 % за счет улучшения координации и упреждающего решения проблем.
Более высокие показатели адаптации пользователей: увеличение адаптации пользователей на 40–50 % на начальных этапах ввода в эксплуатацию благодаря лучшему управлению изменениями и взаимодействию с заинтересованными сторонами.
Оптимизация ресурсов: улучшение использования ресурсов на 25 % за счет лучшего планирования мощностей и балансировки рабочей нагрузки.
Улучшение качества: сокращение критических дефектов на 35 % за счет улучшения координации тестирования и аналитики качества.
Удовлетворенность команды: значительное повышение удовлетворенности проектной группы и снижение выгорания, что приводит к лучшему удержанию талантливых сотрудников.

Заключение

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

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

Источник

Незначительно переработанный материал:

Продукт: SAP Portfolio и Project Management для SAP S/4HANA

среда, 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. Открытие. Здесь - не раскрывается.

среда, 18 июня 2025 г.