Сто имён клиентоориентированности
Клиентоориентированность известна под многими именами, это теперь даже не SoTA, а “гигиена”. В системном мышлении она даётся как необходимость представить себе удовлетворение потребности внешней проектной роли в определённой функции надсистемы целевой системы (и поэтому достижение целевой системой определённого состояния или свойств, в которых эта функция возможна). Всё физично, заземлено, разговор предельно конкретен. Но это может разворачиваться не только для целевой системы, но и для многих других систем в графе создания и в окружении, и там нюансы времени различения времени создания и времени использования (а сами рассуждения ведутся в методологическом времени).
В методологии мы понимаем, что в конечном итоге речь будет идти об изменении физического мира, но обсуждать надо процесс/метод/культуру/методологию – и там появляются некоторые онтологические смягчения, разговор идёт в терминах предметов метода самой разной природы, которые мы моделируем альфами как объектами внимания в проектах. Внимание легко перескакивает с ментальных объектов (например, описаний) на физические (системы) и даже поведения (методы, работы). Разговор продолжается, в каждый момент разговора мы следим за постоянством типов, но уже допускаем менее формальные речевые обороты вроде “существования системы в виде сырья” – понимая, что и зачем так говорится. И тут мы уже можем говорить о прикладных методах работы и их разложениях на составляющие методы, включая “методологии/методы/процессы разработки”/“инженерные процессы” и их описания/теории/frameworks/models (в английском проще всего в запросах к AI указывать development methodologies, frameworks, models – дальше AI сам разбирается с синонимией).
Мы стратегируем методы, планируем и проводим работы, отслеживаем в ходе разработки в конечном итоге альфу (воплощения) целевой системы, которая должна будет удовлетворить потребности (needs) внешних проектных ролей. Эти внешние проектные роли обычно скрываются за словами client, customer, user, consumer. То, что в системном подходе было “от границы целевой системы смотрим сначала всегда наверх, в поведение в окружении во время эксплуатации”, в бизнес-литературе выражается тем, что в название методологии разработки вставляют какой-то синоним (как обычно, тысячи их) ориентированности на клиента/заказчика/пользователя и добавляют focused, centered, driven, first, oriented или даже obsessed в название метода (в том числе бизнес-стратегии, метода разработки, предоставления сервиса, организационной культуры – слово “метод/процесс” тут тоже имеет множество синонимов):
• Customer-focused
• Consumer-focused
• User-centered
• User-centric
• Customer-driven
• Client-focused
• Market-oriented
• Customer-first
• Customer-obsessed
• Customer-led
• Human-centered
• Client-driven
• User-driven
• Customer-oriented
• Service-oriented
• Audience-focused
Поколения системного подхода и клиентоориентированность
Развитие там было примерно такое:
– первое поколение системного подхода делало акцент на технические процессы и минимальное внимание на клиентах (1950-1980-е), ещё до водопада была модель code-and-fix, структурное программирование, затем “водопад” (предложен Winston W.Royce в 1970, хотя он сам и не использовал слово “waterfall”),
– второе поколение системного подхода заметило людей-создателей и внешние проектные роли. После чего заговорили о прототипировании (1980-е) и спиральной модели (1986), в программировании возникла идея reuse и объектно-ориентированного программирования для переиспользования (потом эта идея была похоронена архитекторами). Но там уже была замечена внешняя проектная роль User – и в HCI (human-computer interaction как одной из ветвей software engineering) появился UCD (user-centered design, 1980-1990e). И уже опираясь на это, появился agile с его манифестом в 2001 году – и там идеи активного сотрудничества с клиентом в ходе разработки. Примерно в это же время (2000е) – идеи lean development в agile, где пытались применить принципы Toyota manufacturing system, lean construction в строительстве с тщетными попытками планировать непланируемое. Вот чего там ещё не было, так это идей эволюционности: всё это было медленным отходом от стадийных методологий, даже спираль понималась как “шаги-обороты пошагового процесса”, а не “путешествие” предмета метода с изменением его состояния в причудливом порядке применения разных методов из общей методологии. Даже там, где речь шла о людях (клиентах, например, в маркетинге), были “водопады”, типа той же “воронки продаж” с чёткими сменами состояний. Это всё “до клиент-ориентированности”.
– третье поколение, учёт времени эволюции и “непрерывного всего” начинается в 10е годы, lean startup. Признавалось, что “ничего лишнего”, lean/элегантно – но не только при производстве, но даже и при задумывании продукта, в стартапе. Но как узнать, что там лишнее, а что нет? Вот тут и появляется в самых разных методологиях “ориентация на клиента”: делается не любая система (первое поколение), не система, которая делается в срок и в бюджет и вообще хоть как-то делается (второе поколение), а которую можно продать! И появляются идеи эволюции, включая смену вида систем (виражи). А в случае людей – идеи “путешествия”, признаётся, что людей нельзя заставить пройти через стадии. Тут и Design Thinking, и развитие Human-Centered Design (HCD) на User-Centered Design (UCD) и User Experience (UX) Design, и Agile с Lean Startup Methodology, затем Lean Innovation Management (тут главное было в том, что “не только стартапы, корпорации тоже”!) компромиссы типа SAFe и LeSS, и Jobs to Be Done (JTBD) Theory, Customer Development Model, Service Design, Customer Experience Management (CEM or CXM), тысячи их.
Во всех, конечно, voice of customer с неизбежной критикой (ибо customers при их опросах не могут высказать невысказываемое, “изречённое дао – не настоящее дао”, не ощущают свои боли, явные желания сводятся к “подержи верблюда”, долгосрочное стратегирование у клиентов вообще на нуле – и так далее, список критики длинный). Поэтому первое же там развитие сдвинуло “голос клиента” (понимающийся как голос персонажа из какой-то “целевой аудитории”) на метод работы, который хочет выполнять клиент в своих работах, и дальше смотреть на проблемы этого метода. При этом абстрагировались особенности клиента (возраст, пол, семейное положение и т.д.). Внимание уделяется методам/функциям (поэтому термин был jobs, а не works), а не всему потоку сознания или любым описаниям клиента, которые вычитывали в ранних методологиях клиентоориентированности.
New product development и management
Всё это развивалось очень неспешно, ибо о важности ориентации на клиента, а не на продукт, говорил Theodore Levitt в 60х (в 1969 вышла с этими идеями книжка “Marketing Mode”), Peter Drucker в 60-70х, но всё это были “изыски”, массово в мейнстрим они не шли. Идея “продукт-продукт-продукт” (иногда это был сервис, идея сервис-ориентированности S-D logic была позже), который надо как-то впихнуть клиенту, постепенно заменялась идеей “маркетинга”: надо сначала понять, какой продукт вообще возможно впихнуть клиенту – и разрабатывать только такой продукт (см. в том числе начало краткой истории маркетинга в Иммунный ответ мокрой нейросетки на "маркетинг": ailev — LiveJournal). История делится тут на два направления:
– маркетинг как специфические методы понимания, какой продукт или сервис будет продаваться.
– идеи жизненного цикла со стадиями из системной инженерии, которые показывали, что продукт появляется (и там где-то в начале маркетинг), потом разрабатывается, потом используется, потом отмирает. Вот это получилось название NPD, new product development.
В 1965 году идею того, что с продуктом что-то там происходит в ходе “жизненного цикла” выдвинул в статье “Exploit the Product Life Cycle” в HBR Theodore Levitt, профессор Harvard Business School. Там было понятно, что продукт откуда-то берётся, потом разрабатывается, потом производится, потом используется. Консалтеры из Booz Allen Hamilton в 1982 году выпустили отчёт “New Product Management for the 1980s”, но по факту формализовал подход C. Merle Crawford – у него тоже было много работ с 60х, но вот его книжка 1986 “New Products Management” стала основой подхода – там была предъявлена методология/process NPD, это подхватила в 1976 году образованная Product Development and Management Association (PDMA), при этом иногда термины product development и new product development, а также уточнения, что это менеджмент, или методология самой разработки продукта, или методология менеджмента разработки продукта – это всё пошло вперемешку. Merle Crawford и Anthony Benedetto до сих пор переиздают книжку, обновляя её содержание, последнее издание – двенадцатое, 2021 года, New Products Management
Главное, product development как таковой стал в NPD как-то клиентоориентированным, хотя и кривовато: поначалу там чёткий водопад со стадиями (Stage-Gate Process с Go-No-go решениями предложен в 1986 году Robert D. Cooper): на первых стадиях жизненного цикла принимается решение о том, что это будет за продукт – и маркетинг где-то там, без размышлений о клиенте нельзя! А потом – системная инженерия и системноинженерный менеджмент (SEM), как обычно.
Сегодня new product development чаще всего используется как “синоним с нюансами” для product innovation, product development, innovation management. Нюанс в том, что это подход, отражающий взгляд системных инженеров – и там, конечно, было движение к “непрерывному всему” и третьему поколению системного подхода, но больше у программных инженеров, а если речь идёт о “железных инженерах”, то чаще всего это будут идеи о том, что “не забудьте business and mission analysis, чтобы свериться со стратегией компании, когда берёте в разработку новый проект”, “вы должны помнить, что жизненный цикл – это не только маркетинг, но и проектирование, и изготовление, и использование, и вывод из эксплуатации”, “вы должны моделировать – использовать CAD, статистические модели для проверки рыночных гипотез, и вообще вести себя как инженеры в большом мультидисциплинарном проекте”.
Так что это больше извод SEM (системноинженерного менеджмента), “как организовать процесс системной инженерии, если там вначале что-то надо делать с клиентами”.
Маркетинг: серая зона между инженерами и менеджерами
Но вернёмся к клиентоориентированности и тамошним фреймворкам, методологиям, моделям. Большинство из них уходит от “полного жизненного цикла” NPD. Хотя в современном product development и new product development сейчас речь идёт уже не о жизненном цикле, а о создании (new вот тут, причём потом будет указано, что создают MVP) и развитии/development продукта в ходе “непрерывного всего”, contunuous everything.
Вся “клиентоориентированность” оказывается представлена в методологиях, фреймворках, моделях, которые затрагивают только часть разработки продукта, эти методологии – не полные инженерные процессы, они только часть всего процесса разработки – главным образом та часть, которая как-то выходит на понимание того, что же именно нужно клиенту, а также та часть, которая гарантирует эволюционный характер всей инженерии. Эволюция, развитие – это подчинение всей инженерии необходимости выдвижения “рыночных гипотез” про то, что надо клиенту, а дальше эксперименты с продуктом или сервисом, который должен бы клиента удовлетворить. При этом подчёркивается, что это удовлетворение клиента должно быть лучше, чем удовлетворение клиента конкурентами, а изменения в продукт инженеры должны вносить не медленней, чем изменяется жизнь – в которой меняются потребности клиента, меняются цены, меняются технологии, меняется всё, и меняется быстро.
NPD как широкая инженерная область (хотя это не совсем инженерия, это “системноинженерный менеджмент, SEM”, как организовать инженерный процесс) и менеджмент (бизнес-менеджмент, как организовать работу компании) пересекаются в маркетинге как “серой зоне” между инженерно-менеджерским рассмотрением и бизнес-менеджерским. При этом есть ещё и сомнения, стоит ли вообще различать эти менеджменты – но вроде как “маркетинг” воспринимается как прерогатива бизнесменов, а не инженеров. Вместе с тем NPD чётко говорит, что “как определить, что мы будем выпускать” заботит и инженеров, и менеджеров, а маркетологи хорошо должны знать не только рынок (клиентов), но и продукт.
Скажем jobs-to-be-done менеджеры называют “jobs-to-be-done marketing” (см., например, текст 2011 года в HBR, Clay Christensen’s Milkshake Marketing - HBS Working Knowledge – там это словосочетание использовано именно так: Christensen, who is planning to publish a book on the subject of jobs-to-be-done marketing, explains that there’s an important difference between determining a product’s function and its job. “Looking at the market from the function of a product really originates from your competitors or your own employees deciding what you need,” he says. “Whereas the jobs-to-be-done point of view causes you to crawl into the skin of your customer and go with her as she goes about her day, always asking the question as she does something: Why did she do it that way?”).
“We realized that the causal mechanism behind a purchase is, 'Oh, I’ve got a job to be done.” – важна не функция системы, важен метод действий клиента по достижению цели! И клиент тут “нанимает” продукт. Мы кратенько рассматривали это в наших курсах как разницу в функции/методе, нужном от системы надсистеме для удовлетворения потребности клиента, а не функция/метод, предполагаемый изготовителем – надо стать аффордансом для надсистемы, для этого понимать, что происходит в надсистеме. Понимать, что происходит в продукте, чтобы продукт как-то себя вёл (возможно, не обеспечивая нужную функцию в надсистеме) – маловато. И вот это стык: маркетологи интересуются тем, чтобы продукт как чёрный ящик пригодился для надсистемы – и не просто пригодился, а так, чтобы удовлетворились needs (продукт был нанят и выполнил свою функцию/job в надсистеме так, чтобы надсистема выполнила свою функцию). А инженеры – им надо сделать такой прозрачный ящик, которые выдаст не просто какую-то функцию, а “попадёт” в ту самую нужную для надсистемы – а она, сюрприз, зависит от needs внешних ролей. При этом маркетологу всё равно, что customer это только одна из огромного числа внешних проектных ролей, а инженеру – не всё равно. Тем самым JTBD маркетинг – это часть культуры маркетинга, и от неё маркетолог будет идти дальше к рекламе, продаже, развивать сообщества и т.д., а JTBD у разработчика – часть культуры разработки, чтобы делать то, что надо, а не что хочется или что можется, и от неё дальше будет проектирование, изготовление и т.д. Переход к сервис-ориентированности тут не много меняет, в курсах, повторюсь, это хорошо разобрано.
В любом случае, в героический (героика стартапов! венчуры! хакатоны! десятые годы!) период клиентоориентированность в процессах разработки получает имя outcome-driven (например, outcome-driven innovation, ODI), в этих маркетингово-разработческих (NPD) методологиях акцент не на output (результат работ), а outcome (итоговый совокупный результат: доволен ли в конечном итоге клиент). Это означает, что в 21 веке мысль разработчиков гарантированно заземляется/grounding на клиенте, который рассматривается в ситуации эксплуатации целевой системы (как найти целевую систему в случае сервиса довольно подробно рассматривается в курсе “Системное мышление” и дополнительно в курсе “Методология”). Клиентоориентированные методологии якорят/anchor – эту ориентацию на клиенте через внимание на удовлетворение needs (что там даёт клиенту надсистема, если в её составе эксплуатируется система – время эксплуатации, иногда по этой линии приходится смотреть и на “клиента клиента”, но по этой линии кашу маслом не испортишь, хватило бы мозгов и времени для учёта огромного числа факторов при прихвате дополнительных систем в рассмотрение). Вот все эти outcome-driven (читай “клиентоориентированные”, признающие важность needs) методологии, и явно не все, а которые более-менее “на слуху”:
Outcome-driven innovation и теория Jobs-to-be-done
Outcome-driven innovation (Outcome-Driven Innovation - Wikipedia) от Anthony Ulwick, “What Customers Want: Using Outcome-Driven Innovation to Create Breakthrough Products and Services”, 2005. Первый документированный успех был в 1992, патенты по методологии Ulwik получал ещё с 1999 года, затем публикация в HBR в 2002 году, затем – книжка в 2005 (The History of Jobs to be Done [+ How to Apply It to Your Business], формально JTBD theory была создана в 1990: In 1990, Ulwick created the JTBD theory, suggesting that companies should stop focusing on the product and the customer — and instead should understand the “underlying process” (or job) the customer is trying to execute when they are using a product or service. Грубо говоря, “думай про метод/job, который задействует конечный потребитель, используя продукт или задействуя сервис”. Метод, job ведь – это про “занятость”. Ищи сигнатуру метода (что с чем клиент хочет делать, и зачем), дальше предлагай другое разложение метода с использованием своего инструмента. Клиент тогда “наймёт на работу” твой продукт, если метод с твоим продуктом будет получше (дешевле, быстрей, приятней). Всё то же самое, но другая терминология – и оттуда объяснение через какой-то определённый набор метафор.
Это, конечно, главным образом про потребительский рынок, идеально для всяких “телефонных приложений” и тех ситуаций, когда клиент что-то хочет делать с собой (в курсе “Системное мышление” был пример ручных часов, вспомните).
С идеями Ulwick по outcome-driven development довольно рано ознакомился Christensen (тот самый, который предложил в 1997 году термин “disruptive innovation” и написал “Дилемму инноватора”) он и популяризовал подход с некоторыми добавками своих примеров – он и дал название Jobs-to-be-done (с альтернативой “outcomes that customers are seeking”), в книге 2003 года “The Innovator Solution”, когда идеи Ulwik были известны только по публикации в HBR, то есть ещё раньше, чем вышла книга самого Ulwik. Подход outcome-driven innovation тем самым начал пониматься как происходящий на основе Jobs-to-be-done theory, которую затем тащили в разные предметные области за пределами b2c. В 2016 году Ulwik выпускает книжку уже с термином в заглавии “Jobs to be Done: From Theory to Practice” показывает, как теорию превратить в рабочий метод, в том же году выходит аналогичная книжка Christensen с вариантом этого фреймворка, “Competing Against Luck”). Если сделать этот трюк со сдвигом внимания на метод работы клиента с использованием продукта (job to be done), то Ulwik отмечает многие изменения в онтологизации маркетинговых рассмотрений (What Is Jobs-to-be-Done?. Is Jobs-to-be-Done a theory? A lens? A… | by Tony Ulwick | JTBD + Outcome-Driven Innovation):
– The unit of analysis is no longer the customer or the product, it’s the core functional “job” [functional job – это чтобы вы не перепутали с work, job тут не синоним для work!] the customer is trying to get done.
– Markets aren’t defined around products, they are defined as groups of people [сообщества!] trying to get a job done [вот они, сообщества – как мы и говорим, они объединяются по общим методам/культурам/занятостям своих участников, “занятости” тут отсылают к job]
– Customers aren’t buyers, they are job executors [это у нас исправление ошибки “моментом использования системы будет момент её покупки”, это самая частая начальная ошибка студентов кафедры технологического предпринимательства, да и многих других – им же надо продать, а там хоть трава не расти! Нет, моментом использования будет момент эксплуатации/работы/функционирования системы].
– Needs aren’t vague, latent and unknowable, they are the metrics customers use to measure success when getting a job done. [эта тема выходит на actionable metrics, что требует вообще отдельного разговора – но об этом позже]
– Competitors aren’t companies that make products like yours, they are any solution being used to get the job done [аффордансы могут быть очень разными, а всё новое приходит сбоку – под конкретную сигнатуру может прийти аффорданс совершенно другой природы, это мы подробно разбираем в стратегировании].
– Customer segments aren’t based on demographics or psychographics, they are based on how customers struggle differently to get a job done. [это мы обсуждаем как переход от “метода персон” к рассмотрению методов и внешних проектных ролей не просто “пользователя”, а уточняющих эту роль – скажем, “игрок”, а не просто “пользователь”. Интересно, что JTBD постулирует акцент на методе, роль и её именование по сути опускается – чтобы сразу перейти к “сообществу как группе с какими-то культурами работы”, но рассуждения с точно названной ролью обычно проще]
В jobs-to-be-done и тем самым outcome-driven innovation стараниями главным образом Christensen (самый активный популяризатор, Clayton Christensen - Wikipedia) появились самые разные варианты, например:
– методы (помним, что тут jobs как методы, которыми работает клиент, а не система) как действия (activity), где прямо пишутся “функциональные шаги” (простейшее императивное разложение метода), которые клиент должен предпринять в работе, чтобы получить результат. Инкрементальные улучшения, акцент на “что клиент делает”. Это основная линия рассуждений Ulwik.
– методы-как-прогресс, который интерпретируется как улучшения (progress), которые хотел бы сделать клиент в своей жизни применением метода – ход на “конечное состояние предметов составного метода – в конце, возможно, длинной последовательности действий, outcome в отличие от output одного шага”, “зачем клиент вообще что-то делает”, вопросы мотивации (тут надо помнить, что речь идёт о b2c и помнить, что там разные мотивационные теории типа SDT, и по этой линии практически нет задействования социальных теорий типа SOC – об этой разнице тоже надо будет говорить отдельно). Тут выходится за рамки улучшений в выполнении какой-то задачи/однократного применения рассматриваемого метода, а спрашивается вообще про контекст, про изменения в мире (состояния предметов метода, может быть и самого клиента), которых хочет достичь клиент. Акцент на изменения в жизни, холизм – и тут не только чисто функциональный аспект, но и “культурный фон” (что там надо получить эмоционально, в части культурных предпочтений и т.д., то есть тут вынимается и теория мотивации тоже, а ещё могут выниматься и социальные теории с их выходом на основания мотивов личности).
В JTBD в центре не клиент – это не “клиенто-центрическая” методология, это метод/job там в центре
Когда говорят, что основное в популярности JTBD в сдвиге продуктоцентричности на клиентоцентричность, то хорошо бы поправлять: ещё дальше – с клиента (персоны и даже роли) на метод и ход на стратегирование для клиента: почему он задействует метод.
Популярность тут пришла и из-за того, что огромное число крупных компаний начали использовать ровно вот эти рассуждения, чтобы выяснить эти самые customer jobs – и дальше предложить продукты с улучшенным eXperience (об этом тоже потом напишем). Поэтому появилось огромное число success stories и case studies, в вузах пошло массовое обучение.
JTBD отлично интегрируется со многими другими клиентоориентированными методологиями разработки, они же – маркетинговые методологии (в классическом понимании маркетинга: определить, чем будет выгодно торговать – и найти аргументы для объяснения клиенту его выгод). Конечно, есть огромное число публикаций по поводу этой теории и результирующего современного фреймворка. Вот, например, картинка из исследования 2020 года с альтернативной версией истории JTBD, преодоление противоречий между job с идеей process и идеей progress, но через job steps – вы уж сами как-нибудь с использованием материала “Методологии” отойдите от императивного представления процессов (Synthesizing the Two Schools of Thought—JTBD Progression Part 5 - INNODYN):
Ссылками решил не перегружать, это всё легко гуглится или чатжепетится – но поскольку это вроде как история, то вы найдёте удивительно разные версии истории. Меня тут больше заботит онтология всего рассказанного, умение рассуждать о клиенториентированных методах, сравнивать их и понимать, что у вас там в ваших рабочих проектах.
Продолжение следует, там рассмотрим клиентоориентированность в lean innovation management (всякие MVP, гипотезы и виражи, шаблоны бизнес-моделей – они тут), customer experience management (всякие customer journeys и eXperience тут), а также затронем actionable metrics.