К бизнес архитектору предъявляются различные требония, их можно подчерптунуть из требований вакансий и свести к:
* Знание построения бизнеса в целом
* Личстные навыки
* Выстраивание взаимосвязей вертикальных и горизонтальных
* Технические навыки (доменные)
Рассмотрим разные разносидности ИТ бизнеса, так как это напрямую влияет на работу архитекторов, так как каждая имеет свои характиристики. Можно выделить, хотя, обычно, в то или иной мере, присутсвуют все, но всегда есть основная:
* сервисную (заказную) – компания выполняет заказы и зарабатывает на разнице в стоимости оплаты за работы и за труд;
* продуктовую – компания создаёт продукт для пользователей или для бизнеса – продаёт не сам труд, а копию результата;
* платформенную – строится максимально масштабируемая система и зарабатывается на её использовании, продаёт услуги оказываемый копией результата.
Посмотрим на спрос:
* сервисаная – кастомная разработка усложняет унификацию, что приводит к последующей кастомизации, но не все мало компаний могут себе позволить такую разработку, а кто может позволить, ищет минимальную стоимость, как следствие, привликаются более дешёвые кадры;
* продуктовая – потонциально большая аудитория, которая не готова переплачивать за решения, сделанные индивидуально под них, но универсальные решения более сложны в реализации и поддержки, что требует определённой аудитории для компинсации этого и риска ошибки в спросе (неоднозначность маркетинговых иследований) или в подмене целей (когда PorductOwner заменяет Project Manager);
* платформенные – мультисегментные, но хорактеризуются долгой окупаемостью из за большой сложности и риском конкуренции.
Посмотрим на предложения:
* сервисаная – архитекторам нужно делать PreSale, то есть при минимальных входных данных разработать архитектуру в минимальные строки, обычно, до месяца, так как договор с заказчиком ещё не заключён и он не принял решение.
* продуктовая – если продукты не появляются часто, то степень требуемой квалификации работкников снижаются, и первыми кадидатами на попадания в группу риска явлются архитекторы.
* платформенная – проектируются долго, после обычно перекупают (переманивают) конкуренты, опыт очень ценется, но спрос минимальный.
Книга "Практика менеджмента. Питер Друкер." говорит о том, что нужно для эффективного менеджера, а я сформирую то, как это можно сделать через модель (понимание) бизнеса:
* видеть бизнес целеком – нужна модель; * формирование предпочтений и спрос – упрвление через модель; * управление на основе целей – нужна аналитика по модели; * инновации это риск – нужно планировать и видеть результат заранее через слудующий этап модели; * нужна цифровая обратная связь для мотивации – нужны показатели работы бизнеса.
Для понимания устройства бизнеса расмотрим универсальную модель. Преднозначение модели является снижение сложности реального моделируемого объекта, отража какой-то срез его характеристик. Для понимания бизнеса нам нужно отразить суть происходящего в бинесе, что позволяет бизнесу находить своего покупателя и удовлетворять его потребности. При моделировании крайне важно определить степень абстракции, так как сложные устойчивые системы можно разделить на два класса, в первых устойчивость достигается максимльно жёсткой фиксацией её компонентов для неизменности системы из них состоящей, а во второй – наоборот, максимальной гибкостью компонентов, чтобы изменения одник компенсировались изменения других. Абстрактно, можно первые сравнить с часовым механизмом, а вторые – с шаром наполненным несмешиваемыми жидкостями. При увеличении детализации система становится сложно просчитываемой, но прогназируемой в понятиях компонент, так в часовом механизме можно мерить растояние окружности шестирён (влияние каждого зуба сложно считается), а в воздушном шарике – объём жидкостей разного типа (их форма сложно предсказуема, но подвешенный шар примет со временем устойчивую форму, если не порвётся).
Рамотрим бизнес модель любого предприятия от знаменитого теоретика бизнеса Александра Остервальдера. Эта модель (Business Model Canvas) из себя она преста девять сгруппированных областей, между которыми имеются связи. Слева распологаются обеспечивающие блоки (в проектной архитектуре – обеспечвающий уровень), необходимые для получения прибыли, с права – создание ценностные, которые определяет взаимотношения с потребителями (в проектной архитектуре – бизнес уровень), а между ними – предложение ценности, которое создаётся в левом части и осуществляется предосталвение в правой (в проектной архитектуре – взаимодействие через сервисы). Работа в левой частити и с правой сильно отличаются. В левой части нужно придумать как будет создана инфруструктура, а правой нужно иследовать уже имеющийся потребительский спрос. Подходы мышления тоже отличаются: в левой части мы ищем из множетва решений одно для создания экосистемы (конвергенция), а в правой мы из ситуации предлагаем ножество возможностей для получения обратной связи (дивиргенция). В первом случае этим занимается бизнес архитектор или интерпрайз архитектор, если он прорабатывает не только бизнес слой, а во стором – бизнес аналитик, если прорабатывает бизнес требования или системный аналитики, если он прорабатывает системные требования. Таже отличаются и группы заинтересованных лиц: технический коммитете слева (архитекторы), а справа – управляющий комитет (спонсор, руководитель проекта). Также и в отношении они разыные: правая часть формирует поток доходов, а левая – раходов или себестоимость услуги. Разберём блоки справа: потребительский сегмент связан с предложением ценности через каналы сбыта и отношения с потребителями. Слува распологаются ключевые ресурсы и ключевые действия связанные ключевыми партнёрами.
Более продробно о блоках в правом квадрате:
* потребительский сегмент и широта охвата – определение части пользвателей для того, чтобы более точно удовлетворить их потрубность продуктом;
* уникальное торговое предложение пользовательского сегмента описывает продукт или услугу, которые предотавляются потребительскому сегменту;
* каналы сбыта – способ предоставления продукта или услуги потребительскому сегменту;
* способ отношения с потребителями – способы привлечения, развития и удержения пользователей: индивидуализировнные для долгострочных встраиваний отношния или разовые (Find and forget, обслужить и забыть);
* кто приносит поток доходов, который формируется в вышеаписанном цикле, когда для торгового предложения привлекается сегмент пользователей который чеерз канал сбыта, обеспечивающийся способом отношнеия, получает торговое предлжение.
Резальтатом данной части модели является покток доходов. Рамер потока доходов можно определить мажинальностью и объёмом покупок. Для предсказания есть статистические методы. Маржинальность может быть общей, а может быть сегментированной, в зависимоти от модели зарабатывания. Например, при продаже сотовых телефонов маржинальность может составлять проценты, а маржинальность аксесуаров к ним – сотни процентов, так как маловероятно, что покупатель будет искать чехол в интернете. Или маржинальность покупок устройств около нулевой, а контента на них – высокая. Объём покупок зависи от проведений конверсий на разных этапах. Первая конверсия – широта охвата, которых мы можем показать рекламу (широта охвата). Вторым – сколько вообще могут заинтересоваться ползователей (пользовательский сегмент). Следующей конверсией является ценностной – во сколько потенциальный покупатель оценевает свою потребность и за какую стоимость мы можем предложить её удовлетворение. Последующие – от нас зависящие конверсии, которые могут быть увеличены за счёт таргетирования при поиске или за счёт рекомендаций (социальные сети). Далее идёт конверися процессов, например, от логистики, удобство сайта в покупке, удобрые способы оплаты и быстрая доставка.
Левый квадрат по обеспечения бизнеса:
* обеспечение активами и ресурсами – обеспечение ценности торгового предложения, на котором зарабатывает компания;
* ключевые действия по созанию ценности, то есть те, которые формируют ценностное предложение;
* партнёры помогающие делать ключевые действия и обеспечивать;
* стоимость продукта определяется создаётся и обеспечением его при помощи партнёров.
Результом левого квадрата является различные характеристики сервиса. Например, для гарантии и стоимости: если масштабируемость выше чем нужно, то скорее всего она неоправдано увеличила стоимость, если меньше – это сказалось на стабильности, а для разовой услуги – потеря клиентов, которые не смогли приобрести услугу, а для сервиса, то ухудшение качества. Другим примером может быть таргетирование, когда система сохраняет лаяльность пользователей для которых данная реклама на важна. В этих проектах по таргетированию и обучению рекламодателей ему не влияют на напрямую на денежный поток в конкретной покупке, но они увеличивают лаяльность пользователей в долгострочный перспективе при наличии конкурентов, если у них таргетирование хуже. Таким образом, экосистема преднозначена для того, чтобы обходить конкурентов, предоставляеть сервис по доступной пользователям цене, по достаточным характеристикам для его приобретения и другим точкам роста, не только по цене.
Разберём возможные модели бизнеса для студии по разработки сайтов, магазина, музыкального сервиса, сайта недвижимости, социальной сети:
* потребительский сегмент: владельцы бизнесов, покупатели, слушатели произведений, покупатели недвижимости, заказчики рекламы для социальной сети.
* уникальное торговое предложение: уникальный сайт, доступность (цена, расположение) и ассортимент, контент, подбор недвижимости, ощудения значисости и сопричастности;
* канал сбыта: личный контакт и интернет, посещение и доставка, интернет, интернет, интернет;
* способ отношения с потребителями: индивидуальное с сопровождением и сопутствующими услугами;
* обеспечение активами и ресурсами: сервера для сайтов, арендные площади для магазина, музыкальный сервис, сайт недвижимости, пользовательская база социальной сети;
* ключевые действия по созанию ценности: разработка сайтов, договорённости и логистика с поставщиками, договорённости с музыкантами, недвижимость, вовлечение и удержание пользователей;
* партнёры: разработчики, поставщики, музыканты, строительная компния, источники пользователькой базы;
* стоимость продукта: затраты на разработку и запуск сайтов, расходы на закупку и логистику товаров, закупка лицензий на музыкальне произведения, затраты на постройку недвижимости, стоимостить лида и лояльности.
Не всё однозначно для мультисегментных потрбетеля. При этом разница с певого раза не значчительная. Например, для iTunse патнёрми являются комапании, предоставляющий музыкальный контент, который закупается, а потребителями являются слушатели, который его оплачивают. А вот для Apple Store разработчики не только являются патнёрми, торые предоставляют свои приложения, чтобы бизнес платформы мог зарабатывать, но и являются пользователями платформы, когда эти приложения продают.
Когда процесс не описан и не автомтизирован, то он есть, но всё время разный – значит это не процесс, а проект. Если у этих проектов есть общее – то нужно унифицировать. Для этого понадобится статистика действий, которая приводит к успеху часто. Но, привоводят они к успеху при определённых условиях, в других – нужно действовать по дургому. Для этого нужны эксперты, которые укажут базовые пути прохождения процесса и их развилки. Дальше нужна статистика неудач, их причины и метрики. На основе этих данных процесс регулируется: это может быть как последовательность дейстий, так и корректировака самих действий или же обеспечение этих дейсвий, например, продукт. Со верменем процесс детализируется и подстраивается под большинство вариантов условий, в которых нужно изменить его протекание. Это эволюционное развитие процесса, обычно или постепенно улучшается до определённого порога, когда предложение приближается, или более резко доходит до него, когда нащупа нужный продукт.
Процесно строится:
* поиск пользовавателей придставляющих пользовательский сегмент или других заинтересованных лиц;
* определение потребностей (B2C) или проблемы (B2B) в существующих процесса (интервью, вопросники, ролевые игры, мозговой штурм);
* на сборе требований требований, в том числе и стороны платформы и партнёров;
* прототипирование бизнес проесса и платформы;
* построение архитектуры и налиживание связей;
* разработка платформы и привлечение пользователей.
При посроении бизнес процессов необходмо:
* определить цели и другие метрики;
* технологии: ролевая модель, оргинизационная структура;
* ролевая модель, культура, развитие, ролевой состав людей;
Бизнес процессы необходимо не только описать, но и внедрять измеения, поддерживать, масштабировать и контролировать, а часто об этом забывают. Процессы это срез деятельности, поэтому их можно по разному формализовать и описать как разное количество.
* основные (бизнес) включают продажи, создание продуктов и услуг для покупателей;
* поддерживающие – маркетинг, создание продуктов и услу для внутреннго пользования и другие важные напрямую не приносящие прибыль процессы.
Важно заметить, что заказчик находится в левой части модели, а пользователя в правой. Поэтому, нужно делать продукт под пользователей, чтобы заказчик получал доход или другие приемущества. Есть большая вероятность, что заказчик имеет своё представление о том, что нужно пользователям. Но это знание ограничивается теми продуктами, которые уже у него есть и экслуатируюстя, а не который предпологается создать. Поэтому, важно найти такого пользователя, который являлся бы типовым преставителем сегмента. Баланс размера сегмента определяется при сегментировании – на колько он обособленным является, технически – на сколько ближайшие пользователи к сегменту но вне его отличаются от него. Решение удовлетворяющее роль пользователя, который может находится в разных сегмента полноценно не удовлетворяет ни одного пользователя отдельных сегментов. В случае, если в системе предпологается арзные роли для разных сегметов, то такое решения называют мультисегментным – внём удовлетворяются пользователи арзныех сегментов, но по разному для каждого сегмента. В секторе B2C вложно понять, является ли он типичным пользователейм, возможно, он является пограничным и если мы на него будем ориентироваться, то получем ориентацию на очень узкий сегмент. Другой проблемой является разная готовность пользвателей к изменениям. Распределение по готовности имеет нормалную форму (форму кривой Гауса). В самом начале и их наимьшее количество – новаторы, делее – консерваторы, которые составляют основную часть. Проблема, что в выборке могут оказаться много новаторов, которые будут польоваться просто из интереса и ощущения передовых идей. Обычно, широта сегмета, объёма пользовательской базы и процент новаторов от количества потенциальных пользователей не позволяет продукту быть успешным. Для консерваторов продукт должне быть другим или их необходимо подготовливать небольшими изменения в текущих, нужны отзывы уже пользующихся консервторов. Эти проблемы решается повышением репрезентативности выборки, что означает, что провести не менее 50 интервью с разными пользователями. Если отказыаются, то нужно проробаваться целевую аудиторию и предложвение антервью. Важно проговорить не стеми кто согласился, а со всеми, так как согласившиеся сразу скорее всего по большей части являются инноваторами.
Если в сегмента B2C в заинтересованные лица входи такая абстракция, как сегмет пользователей, на которую крайне сложно как либо повлиять, то в сегменте B2B есть конкретные пользователи являющиеся типовыми представителями заинтересованных сторон с которыми работают также, как и с остальными заинтересованными лицами. Как и в случае с пользователями, которые определяют каким именно должне быть продукт, в B2B нужно найти все заинтересованные стороны, разбить их по значимости (фактическому влиянию) и по типу и возможности влиять на проект, по возможности это изменить, их реальные ожидания и декларируемые ожидания. Это нужно чтобы влиятельных заинтересованных лиц не заитересованных лиц стараться перевести в нейтрально-заитересованных или заинтересованных, а заитересованных привлекать в помощь по заранее определённым ресурсам. Чтобы это успешно делать, нужно знать оличии декларируемых и личных интересов у конкретных заринтересовнных сторон, например, декларируемая заитересованность – за счёт автоматизации сокрещение штата и других расходов комании, личные интересы рукводителя – увеличение его дохода за счёт увеличение штата его подразделения. Отличия от пользователей заключаются в том, что в случае заказной разработки, у заказчика уже есть готовые договорённости, и по этому за основными требованиями можно идти к нему. Но эти договорённости означает, что часть требоний с частью заинтересованных сторон уже формализованы. Под заинтерисованными лицами понимаютя все люди которые имеют какие либо ожидания от самого проекта или его результатов. Частными случаями заинтересованных лиц являются пользователи (бизнес треования), исполнители проекта (системные требования и возможности), руководитель проекта (организационные требования и возможности), спонсор проекта (политическое обеспечение), владельцы бизнес процесов (организация сквозных процессов между подразделениями, иначе очень долгое через эскалирование) представителя регляторных органов. Они могут быть заинтересованы или не заинтесованны в продукте, или быть нейтральны, но в любой момент заинтересованное лицо может перейти из одной категории в другую. Например, из категории нейтральных в категорию не заинтересованных в проекте, после того, если он узнает, что проект реален и может как то повлиять не него. Чтобы это контролировать и регулировать необходимо управлять ожиданиями. При этом, если по PMBook указана организация, то необходимо определить конкретное лицо. Это нужно для того, чтобы определить объявляемые и фактические цели и результаты, которые нужно достич. Как и в случае с пользователями, когда при продаже плеера iPod продаётся ценность, которая является не самим устройством, а доступом к музыкальному контенту, так может покупка компании Motorola покупается не само производство, а его лицензии, так и в случае с проектом, резульатом которого для ряда заинтересованных лиц может быть не сам продукт, а заложенны плане бюджеты, также с заинтерсованными лицами, когда в мероприятия по автоматизации не должно послиять не скрытые процессы. Процесс идентификации заинтересованных лиц и их нетересов нужно проводить как можно раньше, пока у этих заинтересованных лиц не выстроилась позиция по заявляемой части данного проекта.
В B2B сегменте пользователи делятся на две категории, как и в B2C, только не на инноваторов и консерваторов, а на ключевых и рядовых. Ключевые пользователи не представляют интересы радовых – они занимаются сложными кейсами, а радовые с типовыми, они думают не о текущих проблемах, а потенциальных. Но, ключевые пользователи с годами становятся владельцами процесоов, и поэтому с ними нужно налаживать отношения.
Настало время поеределить потребности для B2C и проблемы для B2B, делее составить гипотеных и по их удовлетворению и решению. Сначала нужно определить проблему. Проблема может только назревать, а может уже проявиться. Если проблема проявилась – заказчик сам о ней скажет. Если это не так, то необходимо найти проблему. Процесс преставлется собой последовательность действий и сбои в какам либо звене процесса приводят к проблемам самого процесса. Но, обычно, не понятно, в каком звен проблема. В кризис, когда нагрузка проявляется, проблема видна, но вне кризиса – пролема плавающая. Опросом владельцев систем, обеспечивающих этот процесс, нейти систему, в которой пролема, крайне сложно, так как каждый представитель своей системы будет её защищать. Отмоделировать большие процессы представляется мало эфективным, так как моделирование процессов компании занимает несколько лет, за которое, часто успевают произойти серьёзные изменения, например, реорганизации. Решение может быть поход разбора отдельных проблем и локализованного моделирования дерева причин. Глубина зависит от того, какого размера выбора мы хотим предствить себе в возможноти решения. Наример, сайт был недоступен, так как сервер не работал, сервер не работал та как него небыло некоторое внемя доступа к элетричеству, сбой в подаче электричества случился из-за того, что сеть не подавала наряжения, а сеть – из-за обрыва провода в следствии обледенения. Случившиеся на кадом этапе является следствием одной или несоколькольких пришедствующих причин, помимо случившегося. Так, облединение проводов случилось из-за снегопада в тёплую погоду и от того, что не проводились прафилактические работы по снятию облединения с проводов. Отключение сервера произошло из-за того, что кроме выхода из строя сети, он не задействовал ни генератов автономного энергоснабжения, ни резервную сеть. Приложение перестало работать из-за того, что сервер был отключён, а оно распологалось только на одном серере. Для заказчика оптимальным решением будте то, как оно будет сделано и самим решением. Как оно будет сделано зависит от специализаци. Заказчик может воспользоваться услугами элекроснабжающей организации по снятию облединения, но на посредничестве ИТ компания мало заработает, так он скорее обратится напрямую в эту организацию. Расположить в облаке тоже может быть не выгодно, так как ИТ компании на дорогие тарифы готового облака прийдётся ещё добавлять маржу. А вот созадать ещё один датацентр или сделать резрный генератор позволит улучшить показатели и по другим проектам. Учитывая это, заказчик может получить опреелённые скидки, что ему будет выгоднее. В B2C результативность решения зависит от ожиданий и полуенного результата. Чтобы ожидания не входили за рамки возможного, нужно упрвлять ожиданиями. Для определения самих ожиданий нужно стоить дерево от "хотелок" пользователей, также как и при поиске решений проблем. Назваваетс это дерево решений и оно стоится сперва от инцидента в сторону проблемы отвечая на вопрос "Почему", а потом обратно, отвечая на вопрос "Как" и соотнося свои возможности и интересы, а также приоритеты заказчика.
Далее нам нужно проанализировать проблему. Задать вопросом, почему это проблема ещё не решена. Для этого нам нужно сопоставить проблему с приемуществами возможного решения и проблему с возможным спонсором решения. Например, формы ERP системы крайнер неудобные для пользователей. Причина – формы генерятс из полей базы данных. Решение – сделать индивидуальные формы, но менее универсальные, но порывающие спект за счёт набора форм для каждой группы форм. Спонсор – руководсво компании. Вывод: в случае когда руководству компании не видет заполния форм узким местом в процессе им выгоднее закупать более дешёвы, хоть и менее удобные решения. Отсюда следует, что решение есть, но тот, кто может его применить не видит проблемы.
Проверить решение – на сколько оно качестванное, то есть на сколько оно удовлетворяет треований заинтересованных лиц. Важно, чтобы в его опнимании реение решеало его проблему. Если решение польностью соответвует пожелениям, но он считает, что его проблема не решает его проблему, то можно считать, что проект не состоялся, так как он не бедет оплачен, не смотря на составленные договора и подписанные требования. Это связанно с тем, что заказчику прийдётся обратиться за новым проектом для решения его проблемы. Сами же трбования постоянно меняются, и будут изменены от анализа до реализации не менее ем на 35% по опытной оценке. В B2C после нескольких rework – до почти на 100%, за исключением, наример, технологии. С дургой стороны, при решённой проблеме, требования могут быть прощены из-за неактуальности или на основе их может быть сформирован новый проект. Поэтому, проект строится во круг не трбований, а критерия решённости проблемы заказчика, вносимой в устав проекта. В отличии от многостраничных меняющихся требований, устав занимает пару страниц не не может быть изменён в рамках данного проекта.
Интервьюрирование состоит из:
* Определение поиска интурьвьентов: социальные сети и другое место с целеовой аудиторией для B2C, прямое интервью с целевыми пользователями (для B2B).
* Определение списка вопросов, которые не должны быть прямыми, чтобы не задействать логику и не получать общественно првильные ответы.
* Объяснение интервьенту его роли, результатов интервью;
* Определние контекста: нейтральные вопросы для фиксации настроя и определения точки отсчёта реакции (Small tolk).
* Вводные слова для описания контекста интервью, о бунесе (интерес и проверка на целевую группу) по теме за потраченное время.
* Проявляется эмпатия, определяются потребности и выястняются возможные решения.
* Обработка результатов: на основе потребностей и годных реений выявляются реальные потребности, потребности составлюются в иерархию через вопрос "почуму" и формирование высокоуровневых требовний.
Решение проблемы.
Прототипирование бывает двух видов: горизонтальное (бизнес моделирование) и вертикальное. Подробнее о них:
* Горизонтальное прототипирование ахватывает весь пользовательский путь, а вериткальное охватывает всю шлубино стека.
* На при горизовантальном прототипировании проверяется возможность использования услуги, а на вертикальном – возможность его реализации.
* При горзинальном прототипировании мы снимаем риски пользовательского пути, а при вертикальном – риски.
* Горизональное проектирвоние для сайта может быть проведено на показе дизайнерский моделей интерфейса и отслежвание процесса прохождения по ним пользователя, а при верстикальном – локальное создания технологической экосистемы и отравка тестовый запроса от заготовки интерфейса до базы данных и обратно.
Бизнес строится на пользователях. Пользователями могут быть обыные люди, а могут быть другие компании – это не принципиально. Именно на них бизнес и зарабатывает, что является основной задачей любого бизнеса. Исключением язвляется некомерческие организации, но само слово некомерческие говорит об их исключительности. Поскольку, бизнес строится на взаимоотношениях с пользователями, то всё начинется с определения пользователей (сегментов пользователей) и с помощью маркетинговых иследований определяется какие потребности у них есть и какие може бизнес удовлетворить. Для удовлетворения потребности предлагается сервис в широком смысле этого слова и определяются, какие сервисы будет востребованы у пользователей и на сколько они выгодны. Когда сервис определён, нужно определить, что нужно сделать, чтобы предоставить сервис и как им воспользуется потенциальный пользователь. Последовательность действияй пользователя по пулучения сервиса называется клиентским путём, про предосталения – бизнес процессом. Если в рамках клиенского пути клиент получает удиничных сервис, то его принято назвать услугой, а если в рамках клиенсткого пути получает комплес сервисов – продуктом. Например, выдача кредита – продукт, состоящий из сервисов по предоставления оценки, изготовлния банкоской карты и по выделению денежных средств. В это же время, перевыпуск карты в случае её утраты – услугой со своим выделенным клиенстким путём. За клиентский путь отвечает владелец клиенского пути, обычно, это руководитель депортамента, в рамках которого он предосталяется. За услугу отвечает ProducOwner, за продукт – руководитель подразделения, в рамках которого они обеспечиваются. Рассмотрим, как из каких этапов состоит работа с клиентскими путями. Владелец пути постоянно определяет точки роста (возможности постепенных улучшений) и угрозы (конкуренты, изменнения законодательства) для оперативного изменения клиенсткого пути. Клиентский путь необходимо изменять постепенно, даже если изменения нужно провести большие. Считается, что изменения не должны привышать 15%. Это нужно, чтобы пользоватли смогли адаптироваться к предстаящим изменениям. Исключением язвлется редизайн, когда есть революционные измения, которые не достич эволюционным способом, но при редизайне не изменяется текущий, а создаётся новый, а старый или продолжает сопровождаться, или архивируется. Например, взамен стандратного интерфейса сайта для молодёже был разработан интерфейс Flat с плиточками и другой структурой. Пользователям предлагается на старой версии переключить интерфейс на новый с возможностью вернуться обратно с традиционному. Например, так было в инфтерфейсе Google AdWords. Конечно, процесс изменения клиентского пути состоит из нескольких этапов, причём они образуют цикл. Рассмотрим их по методологии PDCA (Plan, Do, Check, Art):
* планирование изменений – мониторинг необходимых изменений для улучшения пути или для подстройки под изменившиеся условия, проектирование нужного состояния (TO BE), анализ способа перехода (GAP анализ) из описанного текущего состояния (IS AS) в спроектированное (TO BE).
* внедрение измененей – внедрение изменений в процессы для перехода в спланированному состоянию (TO BE) пути с учётом компетенций и других возможностей при постоянном контроле продвижения к цели.
* управление текущими путями (внедрение) – управленияе эфективностью использования новых или обновлённых процессов с помощью анализа пользовательский метрик по удовлетворённости клиентов, положительного клиетского опыт и достижения ими цели, и метрик компании по эфективности пути, размера рисков и отклонений от целей.
* актуализация процесса (эксплуатация) – перестройка метрик после изменений в клиентском пути с помощью оптимизации, а если не даёт результата – производим редизайн пользовательского пути или отдельных процессов.
Методология решения проблем PDCA аналогична PDSA (Plan-Do-Study-Act) и похожа на DMAIC (Define, Measure, Analyze, Improve, Control). Цикл Деминга для PDSA аналогичен циклу Шухарта для PDCA. В ней Plan соответстует Define, Measure, Analyze, остальные коллерируют.
Если постепенное изменение метрик при отптимизации продолжительное время не приносят результата, необходимо одновременно повысить качественне и количестенные показатели, было принято решние по смене технологической базы, то применяется редизайна процессов и путей. Например, редизайн процесса требуется, если удешевления было принято решние проводить за счёт отказа от лицензионных отчислений путём перехода с проприетарного обеспечения на комплекс OpenSource решений, покрывающих многостороннесть проприетарных возможностей. Редизайн процессов требуется при замене трандиционный технологий взаимодействия с пользователями на Artificial intelligence (AI), Robotic process automation (RPA), AI-ботов, Internet of things (IoT), Computer vision (CV), Gamification, Virtual reality (VR), Augmented reality (AR), биометрии. Редизайн осуществляетя как обычный проект от проектирования до экслуатации.