%% **Оригинал:** [[1-4 Описание проблемной ситуации в системе]] **Версия:** 2025-11-11 **ProjectId:** 442 **Путь:** 40 Образование/442 - Введение в системное мышленпие/1-4 Описание проблемной ситуации в системе.md %% %% - [ ] #t Опубликовать документ 📤 #442 [created:: 2025-11-11] %% %% - [ ] #t Опубликовать документ 📤 #442 [created:: 2025-11-11] %% Up:: [[psf-Материалы курса Введение в системное мышление|Материалы курса Введение в системное мышление]] Образовательные результаты: - понимает логику шаблона A3 (план изменений); - выбирает нежелательное явление или шаблон поведения требующих изменений; - формулирует определение проблемы ("разница между желаемым и воспринимаемым, расхождение между "Хочу" и "Есть", между теми ситуациями (обстоятельствами), в которых находится сейчас, и теми, в которых хочет оказаться в будущем); - понимает разницу между проблемой и возможностью; - понимает, как определить проблему, требующую решения; - описывает проблемную ситуацию (контекст), который окружает проблему; - понимает, почему важно учитывать стейкхолдеров при описании проблемной ситуации. Ссылка на описание сквозного кейса: [https://www.notion.so/sbre/5181627ca5be440aa53fc583eafc350b](https://www.notion.so/5181627ca5be440aa53fc583eafc350b?pvs=21) --- --- В первых трёх уроках этого модуля вы освоили теоретическую базу, необходимую для работы с проблемными ситуациями в системах. Пришло время обратиться к практике. В этом уроке вы соберёте все полученные знания, чтобы начать работу с шаблоном А3, о котором мы уже упоминали в начале курса. Важно разобраться с тем, как происходит проблематизация. Так называют переход от ситуации, в которой вы чувствуете неудовлетворённость и хотите нечто исправить, к чётко сформулированной проблеме и пониманию того, что именно требуется предпринять. Кнопка: Вперёд ## Шаблон А3 — вспоминаем логику заполнения Шаблон А3 (A3 Problem Solving Template) — это основной инструмент работы с изменениями, который мы предлагаем использовать в этом курсе. Он возник благодаря компании Toyota, ещё до эпохи компьютеров. A3 — это просто крупный формат листа, на котором инженер должен был уместить всю важную информацию: от описания проблемной ситуации до того, какие решения предстояло принять. Такой шаблон можно сравнить с правилами анализа произведения и композиции, которые помогают школьнику или студенту выстроить свои мысли в нужной последовательности и написать сочинение. Шаблон А3 помогает структурировать работу с проблемой. Но помните, что сам по себе шаблон — это пустая форма, последовательность этапов анализа. Он не подскажет, что следует делать и как. Для того чтобы разобраться с этим, нужно применять другие методы системного мышления. Как вы помните, шаблон состоит из шести шагов.  - таблица | **1. Описание проблемной ситуации** **(As-Is)** | **4. Формирование образа результата** **(To-Be)** | | --- | --- | | **2. Анализ проблемы (Why?)** | **5. План действий (To-Do)** | | **3.** Выбор решения и мотивация **(What for?)** | **6. Определение контрольных точек (When?)** | Как с таким шаблоном работать? Начнём с его первого блока. Кнопка: Идём дальше ## Описание проблемной ситуации Часто, сталкиваясь с проблемой, мы пребываем в плену иллюзии: мол, нам про неё всё понятно. Надо сделать первое-второе-третье — и она окажется решена. Мы начинаем действовать — и тут оказывается, что существуют люди, которые возражают против наших решений. Или потом выясняется, что наши действия ведут к последствиям, которых мы и предположить не могли. Так что всё выходит как в бессмертной фразе Черномырдина «хотели как лучше, а получилось как всегда». Чтобы не попасть впросак, нужно подойти к задаче системно и в самом начале зафиксировать ключевую информацию о проблеме и её контексте. Из этого описания должно быть понятно:  - текст - (а) что именно вас беспокоит: - какие нежелательные явления вы наблюдаете; - какие желательные явления вы хотели бы увидеть. - (б) почему вас это беспокоит: - почему эти явления нежелательны — какой вред они наносят; - какой ущерб наносит проблема, насколько он серьёзен, какие возможности вы из-за него упускаете. - (в) в каких обстоятельствах происходит то, что вас беспокоит, каков контекст проблемы; - (г) кто ещё, помимо вас, вовлечён в проблемную ситуацию; - (д) что, на ваш взгляд, позволит устранить (решить) проблему, как ситуация должна измениться в лучшую сторону. Описывая проблемную ситуацию, вы, вероятно, столкнётесь с тем, что какой-то информации не хватает. Составьте список того, что ещё предстоит уточнить или выяснить. Он вам потребуется на этапе анализа. Пункты (а) и (б) похожи, но их не следует путать. (А) содержит факты, (б) — объяснения того, почему их требуется изменить. Описание проблемной ситуации также обязательно включает перечисление стейкхолдеров и их предполагаемого отношения к проблеме — пункт (г). Это необходимо, чтобы наметить план анализа проблемы. В нём важно учесть не только ваши представления, но и мнение других заинтересованных лиц. При этом наши представления о составе стейкхолдеров, их желаниях и целях могут измениться после проработки следующего этапа шаблона — глубокого анализа проблемы. Также обратите внимание на пункт (д). В этой части шаблона вы описываете не способ устранения проблемы, а желаемый результат: ситуацию, в которой проблема устранена. При этом способ достижения результата будет избран позднее. Кнопка: А можно пример? ## **Пример: как описать проблемную ситуацию** Представьте компанию, которая продаёт свой продукт корпоративным клиентам и оказывает им услуги технической поддержки. Но что-то идёт не так. От различных источников, включая руководство фирмы, поступают сигналы о том, что качество техподдержки падает. Нужно разобраться. За это берётся Максим, который возглавляет эту службу. **(а) Какие нежелательные явления наблюдает Максим** Исполнительный директор на квартальном совещании заявил**,** что техподдержка работает недопустимо долго, а инциденты разбираются некачественно. В клиентский отдел поступают сигналы от аккаунт-менеджеров по работе с клиентами, что те думают о переходе на продукты конкурентов. Сами сотрудники службы поддержки жалуются, что решение проблем требует внимания разработчиков, а те постоянно заняты. Выход из внештатных ситуаций происходит крайне медленно, клиенты недовольны. Заметим, что на этот момент у Максима больше нет надёжной информации. Действительно ли таких инцидентов много, стало ли их больше за последнее время, а если да, то с чем это связано, пока непонятно. Если в распоряжении Максима есть средства оперативной аналитики, которые за 5–10 минут позволят получить ответы на эти вопросы, следует этим заняться уже сейчас. Если таких средств нет, то нужно идти дальше. Можно вспомнить, поднимались ли аналогичные проблемы на прошлом квартальном совещании, т. е. возникали ли они в прошлом. При этом, если в тот раз о них не говорили, это не значит, что их тогда не было. Возможно, они уже появились, но ещё не были настолько масштабными, чтобы стать объектом обсуждения. **(б) Почему нежелательные явления беспокоят Максима** На этом этапе происходит субъективная оценка ситуации. Дело в том, что клиенты почти всегда недовольны техподдержкой и регулярно мониторят рынок в поисках альтернатив. Техподдержка едва ли может быть идеальной, но критически важно, чтобы её качество было приемлемым. Обычно это означает, что проблемы клиентов, которые возникают из-за инцидентов, решаются в рабочем порядке и не приводят к конфликтам. Однако бывают ситуации, когда на рынке появляются новые перспективные альтернативы. В таких условиях качество техподдержки может стать решающим фактором при принятии клиентом решения, оставаться ли с компанией и её техподдержкой или нет. Наконец, важно учитывать атмосферу внутри самой службы техподдержки, которая может быть известна Максиму. Ощущается ли там напряжённость между сотрудниками, насколько она сильна и какова её природа?  Например, там может существовать общее мнение, что разработчики делают ляпы в продукте и игнорируют обращения по инцидентам, а крайней оказывается техподдержка. Клиенты её ругают, премии её сотрудникам режут — и всё это незаслуженно. Таким образом, чтобы разобраться в сути проблемы, нужно обратиться к нескольким уровням системы: уровню компании и её взаимоотношений с клиентами; уровню взаимоотношений техподдержки с другими отделами; уровню отношений внутри техподдержки. Предположим, что Максим сформулировал суть проблемы следующим образом: «Кажется, что за последние четыре месяца возросло число инцидентов, которые кажутся клиентам серьёзными и долго решаются. Это привело к тому, что ситуация вышла на уровень аккаунт-менеджеров и исполнительного директора. Если всё не решить силами службы техподдержки, то её ожидает внешняя реорганизация». Слово «кажется» в начале формулировки означает, что гипотезу о возросшем количестве инцидентов надо ещё подтвердить в ходе анализа. **(в) В каком контексте возникла эта проблема** На этом этапе Максиму нужно очертить контекст, который, возможно, связан с возникновением проблемы: - За последние три месяца вышло два крупных обновления с новой функциональностью, востребованной клиентами. Связаны ли с этим нежелательные явления — отдельный вопрос, на который Максим будет отвечать на следующем этапе анализа. Дело в том, что при выпуске новых функций часто нарушается устойчивость старых. Однако действительно ли это произошло, ещё нужно выяснить. - Расширилась клиентская база — появилось большое число новых пользователей. - Изменился состав команды технической поддержки — пришло много новых сотрудников. При этом Максим ничего не знает о качестве обучения новых подчинённых — это тоже вопрос, на который предстоит ответить на этапе анализа. Кнопка: Вперёд Итак, Максим описал контекст, в котором возникли нежелательные явления. Благодаря этому получилось выделить несколько пунктов для дальнейшего анализа:  - текст (1) связь проблемных инцидентов с обновлениями; (2) связь проблемных инцидентов с приходом новых сотрудников и их уровнем квалификации; (3) связь проблемных инцидентов с притоком новых пользователей. **(г) Кто вовлечён в ситуацию** Ответ следует из предыдущих пунктов: сама служба поддержки, разработчики обновлений, исполнительный директор, аккаунт-менеджеры, клиенты. Суть позиций каждой из этих сторон известна лишь частично и тоже подлежит анализу. Например, заявление аккаунт-менеджера «из-за проблем наш клиент два дня не мог выполнять заказы своих потребителей, понёс убытки, он от нас уйдёт» вполне может быть преувеличением. Клиент не смог выполнить всего три заказа при потоке в 100 заказов в день. Это неприятно, но не критично. Правда, если окажется, что это три самых крупных заказов клиента, это, действительно, проблема. Существует возможность, что система нашей компании не смогла обработать эти три заказа именно потому, что они самые крупные и нестандартные. В конце этого шага работы нужно составить список лиц, вовлечённых в ситуацию. Но этого мало — следует ещё продумать то, как вы будете учитывать их интересы при анализе ситуации. Клиентов и пользователей много — всех по отдельности не опросишь. **(д) Как может выглядеть ситуация после устранения проблемы** Ответ Максима здесь такой: «Разбор инцидентов происходит в рабочем порядке, не ведёт к негативу во взаимоотношениях с клиентами и эскалации конфликтов». На этом этапе ещё рано выбирать метод решения проблемы. Даже если анализ покажет, что она связана с реакцией разработчиков на инциденты, то решений может быть минимум два: а) научить службу техподдержки работать с инцидентами без разработчиков или б) договориться с разработкой о том, что она будет быстрее реагировать на запросы техподдержки. Если анализ покажет, что проблемы связаны с выпуском нового функционала, созданного по принципу «лучше сейчас с ошибками, чем без них, но потом», решения потребуют комплексного подхода. Если для клиентов настолько важны новые функции, что они готовы мириться с ошибками, важно придумать, как отстроить процессы. Возможно, сотрудники техподдержки должны пройти особую подготовку, или стоит их заранее познакомить с новыми функциями, пригласив поучаствовать в их тестировании. Решения всегда есть, но чтобы остановиться на одном из них, важно сначала провести анализ. Итак, вы видите, как строились рассуждения и действия Максима на первом этапе работы с проблемой. Посмотрим, как оформить полученные результаты в тезисы и заполнить первый блок шаблона А3. Для этого воспользуемся следующей структурой. Кнопка: К шаблону # Краткая формулировка проблемы  - оригинал таблицы  Опишем проблемную ситуацию, которая сложилась в нашей компании.  - текст таблицы | Проблема … | Техподдержка работает долго, инциденты разбираются некачественно, в клиентский отдел поступают сигналы от аккаунт-менеджеров, что клиенты думают о переходе на продукты конкурентов. | | --- | --- | | Затрагивает … | Службу поддержки, разработчиков обновлений, исполнительного директора, аккаунт-менеджеров, клиентов. | | **В результате чего** . | За последние четыре месяца возросло число инцидентов, которые кажутся клиентам серьёзными и долго решаются. Это привело к выходу проблемы на уровень исполнительного директора и аккаунт-менеджеров. Если ситуацию не решить силами службы поддержки, то её ожидает внешняя реорганизация. | | Успешное решение должно | Разбор инцидентов происходит в рабочем порядке, не ведёт к негативу во взаимоотношениях с клиентами и выходу конфликтов на уровень руководства компании. | # Подведём итоги Закрепим всё вышесказанное чек-листом. Вы можете скачать его и обращаться к нему при необходимости. [Описание проблемной ситуации.pdf](%D0%9E%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5_%D0%BF%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D0%BD%D0%BE%D0%B9_%D1%81%D0%B8%D1%82%D1%83%D0%B0%D1%86%D0%B8%D0%B8.pdf) - Текст чек-листа: Описание проблемной ситуации включает: - (а) что именно вас беспокоит: - какие нежелательные явления мы наблюдаем; - какие желательные явления мы хотели бы видеть; - (б) почему вас это беспокоит / что это вам даст: - почему эти явления нежелательные — какой вред они наносят; - какой вред или упущенные возможности происходят из-за недостаточно хорошей работы, тут надо различить эстетические недостатки от упущенных возможностей; - (в) в каких обстоятельствах происходит то, что вас беспокоит — контекст проблемы; - (г) кто ещё, кроме вас, вовлечён в проблемную ситуацию; - (д) что, на ваш взгляд, является устранением (решением) проблемы — как ситуация должна измениться в лучшую сторону. Также помните, что, описывая проблемную ситуацию и её негативное влияние, полезно дать оценку на двух уровнях — той системы, к которой непосредственно относится проблемная ситуация, и надсистем, которые расположены выше. Кроме того, на этапе описания ситуации могут формироваться вопросы, на которые предстоит ответить на этапе анализа. Они касаются моментов, в которых вы не уверены, или информации, которой вам пока не хватает. В примере, описанном выше, к таким зонам незнания относится, например, связь проблемных инцидентов с приходом новых сотрудников и их текущей квалификацией. На этом же этапе можно составить рабочий список гипотез о путях улучшения ситуации. Они станут основой для следующего этапа — анализа. --- --- --- - Подвал: БД: очень хочется сформулировать логику проблематизации. Т.е. как от описания ситуации , переходить к проблематизации: ситуации с четким описанием мотивации к изменениям , которая направляет размышления На этом я завешаю описание примера, но хочу сделать еще несколько замечаний. Во-первых, часто задача от топов ставится более конкретно, в виде указания: «сократить время реакции и качество решения инцидентов» или «повысить удовлетворенность клиентов». Это означает, что кто-то уже сделал часть работы и сформулировал целевой результат. Но при этом далеко не факт, что эта часть работы сделана качественно. Так что проблему на этапе анализа мы предусматриваем проверку, что проблема носит именно такой характер. И отметим, что эти приведенные два варианта формулируют разные проблемы, с разными критериями результата. Во-вторых, если мы пошли решать проблему «сократить время реакции и качество решения инцидентов», а на этапе анализа выяснили, что проблема вовсе не в этом, конкретные инциденты решаются примерно в те же сроки с тем же качеством, что и раньше, просто их стало намного больше, потому что, например, расширилась клиентская база, и появилось много клиентов, которые не знакомы с продуктом, то мы фиксируем это в описании проблемы как ситуацию, которая в ходе анализа не подтвердилась, и делаем новое описание проблемы «разработать способы онбординга новых клиентов, чтобы у них не возникало такое большое количество инцидентов, ведущее к негативной оценке продукта и негативному пиару», или что-то подобное. И это изменение надо обязательно не только зафиксировать самому, но и убедить всех стейкхолдеров, выявленных в ходе описания проблемы и анализе ситуации? включая топов, но не ограничиваясь ими. И получить подтверждение, что да, они согласны с таким изменением. В-третьих, на этапе формулирования проблемы очень важно зафиксировать, чью проблему мы решаем на самом деле.  Есть неявные полагания, что повышение качество техподдержки должно решать проблемы пользователей. повышать их удовлетворенность. Однако, для корпоративных продуктов мнение пользователей часто не является определяющим, они не выбирают продукт, а работают с тем продуктом, который для них купили. А повышать удовлетворенность купленным продуктом у лиц, принимающих решение об его использовании в корпорации можно различным способом. А техподдержка должна быть лишь «достаточно качественной», приемлемой. И надо выяснять и превращать в объективные измеримые характеристики критерии этой приемлемой техподдержки на этапе анализа ситуации. А для этого – заложить такие вещи в формулировку проблемы. А может быть задача тотального сокращения расходов на техподдержку при уверенности. что пользователям деться некуда. Именно такую задачу решает внедрение чат-ботов в некоторых корпорациях, которые организованы таким образом, чтобы выйти на контакт с человеком было невозможно. Вы можете сами вспомнить такие примеры у банков, авиакомпаний и других корпораций. При этом в других компаниях чат-боты выполняют понятную роль, отсекая типовые варианты проблем и маршрутизируя обращение к нужному специалисту, ценой не критичного раздражения потребителя. Что ещё важно знать про этот этап? Предполагается, что описание проблемной ситуации формулируется за достаточно короткое время. Если же в ходе анализа оказывается, что решать надо совсем другую проблему, то правильный подход – сделать новую форму, а эту – сохранить для истории с резюме-объяснением, почему данную проблему не стали решать.  ### Изначальная версия урока В рамках курса мы учим применять системное мышление для решения проблемных ситуаций. Для работы с проблемами Тойота в свое время создала специальный **шаблон A3 (A3 problem solving template)**. Предполагалось, что сотрудник, встретившийся с проблемой и желающий ее решить, может пойти по этому шаблону, просто заполняя его. Это было еще до эпохи компьютеров, и A3 – формат листа, на котором все должно было поместиться, компактное представление действий. В курсе мы будем использовать упрощенный и адаптированный шаблон. При этом надо понимать, что шаблон задает форму представления, а содержание получается с помощью конкретных методов, входящих в пакет методов системного мышления. Шаблон лишь дает последовательность этапов размышления, но не содержание. Шаблон состоит из шести частей, задающих последовательность действий. И для начала опишем их, включая краткие отсылки к конкретным методам мышления. В этом уроке мы познакомимся с теми, которые применяются на первом шаге – для описания ситуации, а следующие шаги будут рассмотрены в следующих уроках. ## Части шаблона **(0) Заголовок – название проблемы** и проекта по ее устранению. **(1) Описание проблемной ситуации**. Часто его называют описанием AsIs, но это не совсем верно: описание формулирует проблему и окружающий контекст, который имеет к ней отношение. Из него должно быть понятно: (а) что беспокоит, (б) в каком контексте это разворачивается; (в) что является устранением (решением) проблемы – как ситуация изменится. Описание обязательно включает стейкхолдеров разворачивающейся ситуации и предполагаемое их отношение к проблеме, которое может измениться после следующего шага – глубокого анализа проблемы. А про описание устранения проблемы важно, что в этой части мы описываем не способ ее устранения, а именно результат: ситуацию в которой проблема устранена. А способ будет сформулирован позднее. Это требует пояснения на примере, но пример будет после описания. Предполагается, что описание проблемной ситуации формулируется за достаточно короткое время. Оно может уточняться на последующих этапах, но не принципиально. А если в ходе анализа оказывается, что решать надо совсем другую проблему, то правильный подход – сделать новую форму, а эту – сохранить для истории с резюме-объяснением, почему данную проблему не стали решать. **(2) Анализ проблемы**. Мы анализируем причины проблемы. Очень часто в описании – лишь симптомы, а корневая причина – в другом. Это аналогично работе врача при поиске болезни, опираясь на разные симптомы. На этом этапе проводится исследование со стейкхолдерами для выяснения их взгляда на проблему. А также формулируются принципиальными варианты решения с их влиянием на проблемы и возможные последствиями. **(3) Цель и мотивация**. На этом этапе, исходя из первоначального описания и проведенного анализа, мы формулируем цель решения проблемы и фиксируем нашу мотивацию для такого решения и отношение других стейкхолдеров к этому. И фиксируются критерии успеха – как мы зафиксируем, что проблема действительно решена, были получены конкретные выгоды, а не просто было потрачено время и силы на какие-то действия. **(4) Образ результата** (описание ToBe). Разрабатывается принципиальная конструкция изменений, которые предполагается сделать, а также целевая картина ситуации, к которой мы должны придти. **(5) План действий** (ToDo). Набор шагов, которые мы предпримем для решения проблемы. В сложном случае каждый шаг включает не просто набор выполненных действий, но и результат изменений, которые должны произойти, и мы проверяем, что это достигнуто. **(6) Контроль результатов**. Эта часть заполняется по мере выполнения действий и фиксирует фактические действия, которые могут отличаться от запланированных, и достигнутые результаты, которые также могут отличаться результаты от плановых. И тут надо помнить, что наша цель – решить проблему, а не выполнить план. Об этом часто забывают. ## Простой пример Рассмотрим, как работает шаблон А3 на простом и понятном примере из жизни. То, что пример – простой вовсе не означает, что он находится в области простых решений по Кеневин: пример социальный, а люди – это не-простые системы, а сложные, а чаще – запутанные. Итак, проблема: маленький ребенок кричит и тащит маму в магазин, потому что хочет мороженного, происходит это все во время прогулки рядом с магазином, но мы не просто гуляем, а идем в поликлинику (или по каким-то еще делам). Устранением проблемы будет то, что ребенок перестал кричать и продолжили прогулку в соответствии с планами. А вот способ может быть различен, и иметь различные последствия. Можно зайти в магазин и купить то, что он хочет, но он же захочет немедленно съесть, и потом не будет обедать, кроме того мы можем опоздать в поликлинику, если сейчас будем это мороженное есть. А еще дома, где мы планируем пообедать, у нас бабушка, которая, узнав про мороженное, будет сильно ругаться. Таким образом, появляются более сложные способы решения проблемы. Можно договориться с ребенком, что в магазин за мороженным мы зайдем на обратном пути, и съедим его дома.  Можно заменить мороженное на киндер-сюрприз, который купим немедленно, а вот вскроем дома и съедим после еды. О чем можно и о чем нельзя договориться с конкретным ребенком зависит от предыстории отношений. Наконец, есть вариант применить силовое воздействие и обеспечить послушание ценой всплеска эмоций. Все эти способы, а также интересы стейкхолдеров (бабушки), которые находятся вне ситуации выявляются на **этапе анализа проблемы**. А дальше мы **выбираем конкретный способ**, и **фиксируем образ результата** уже детально: мы договорились, что вместо мороженного купим киндер-сюрприз, который принесем домой и откроем после еды, а ребенок за это послушно пойдет в поликлинику и не будет там устраивать скандалы у врачей. Ну и дальше возникает план, который корректирует текущий план действий. Ведь, которым киндер-сюрприз предусмотрен не был. Включая слова, которые скажем бабушке, чтобы обеспечить хорошее восприятие. И он осуществляется. Или **не** осуществляется, потому как детям свойственно забывать о договоренностях, и, если это кажется вероятным, то надо подумать о точках ветвления и предусмотреть альтернативные сценарии, например, в виде каких-то слов с напоминанием о договоренностях. ## Сложный кейс Теперь рассмотрим реальный кейс из бизнеса. Пусть есть компания, которая продает свой продукт корпоративным клиентам и, как часть обслуживания, оказывает им услуги технической поддержки. И есть ощущение неудовлетворенности качеством технической поддержки, сигналы о корой поступают к руководителю службы технической поддержки из различных источников, включая топов компании, которые призывают «разобраться с ситуацией». Очень часто начальное состояние именно таково, а если со стороны топов идет указание «сократить время реакции и качество решения инцидентов» или «повысить удовлетворенность клиентов», то это означает, что кто-то уже сделал часть работы и сформулировал целевой результат. Заметим, что описанные два варианта – это ***разные*** варианты задачи, с разными способами оценки результата. При этом далеко не факт, что эта часть работы сделана качественно, в том смысле, что их проверка на этапе анализа подтвердит, что проблема носит именно такой характер. Кроме того, при превращении проблемы в задачу часто имеются неявные ограничения, например, по стоимости решения. Например, чтобы численность и зарплаты службы поддержки не сильно выросли, и это может отсекать вариант «нанять больше сотрудников». Однако, такие ограничения часто носят более сложный характер. в том числе связаны с распределением ответственности. Например, анализ может показать, что проблемы связаны с частой необходимостью привлечения разработчиков для решения проблемы, а они загружены разработкой и не хотят отвлекаться на поддержку. И тут появляется целый спектр решений: можно выделить квоты участия разработчиков в сопровождении, можно устроить обучение сотрудников службы поддержки, можно начать вести собственную базу данных по инцидентам, в которой можно будет быстро решения для часто встречающихся инцидентов, и так далее. Все это представляет собой набор гипотез, которые должны быть подтверждены или опровергнуты далее в результате анализа ситуации. А далее, на этапе постановки целей надо будет выбрать ту конкретную проблему, которую мы хотим решить, и ожидаемый результат, на следующем шаге – сформулировать образ результата, а затем – план достижения этого результата. Но, что важно, каждый из принципиальных способов решения несет свои затраты, как временные, связанные с осуществлением плана изменений, так и постоянные. Например, обучение сотрудников службы поддержки надо будет провести однократно, но затем, по мере прихода новых сотрудников. их тоже необходимо обучать. А решение по ведению базы знаний требует не только первоначального наполнения, но и организации процесса постоянного ведения этой базы, а также учить новых сотрудников пользоваться этой базой знаний. И для всего этого есть неявные рамочные ограничения по связанным с этим трудозатратам и накладным расходам, причем они различаются для разных способов, то есть их нельзя сформулировать заранее. А еще анализ может показать, что большое количество инцидентов и сложность решения обусловлено текущим качеством продукта, при разработке которого принято сознательное решение жертвовать качеством ради нового функционала, необходимого для продвижения продукта. И это может быть как временная ситуация, связанная с каким-то крупным релизом, который планируется стабилизировать, а может быть регулярной ситуацией, которую надо решать на регулярной основе, учитывая такой характер нагрузки на службу поддержки. И решения тоже могут быть различны. например, участие сотрудников поддержки в тестировании нового функционала. При этом в тестировании могут принимать участие как опытные сотрудники, так и новички, это может быть частью процесса онбординга и знакомства с продуктом, при том, что их качество тестирования будет ниже. Работа со сложными областями как раз отличается наличием таких комплексных решений, которые влияют сразу на несколько факторов. На этапе формулирования проблемы очень важно зафиксировать, чью проблему мы решаем на самом деле.  Есть неявные полагания, что повышение качество техподдержки должно решать проблемы пользователей. повышать их удовлетворенность. Однако, для корпоративных продуктов мнение пользователей часто не является определяющим, они не выбирают продукт, а работают с тем продуктом, который для них купили. А повышать удовлетворенность купленным продуктом у лиц, принимающих решение об его использовании в корпорации можно различным способом. А техподдержка должна быть лишь «достаточно качественной», приемлемой. И надо выяснять и превращать в объективные измеримые характеристики критерии этой приемлемой техподдержки на этапе анализа ситуации. А для этого – заложить такие вещи в формулировку проблемы. А может быть задача тотального сокращения расходов на техподдержку при уверенности. что пользователям деться некуда. Именно такую задачу решает внедрение чат-ботов в некоторых корпорациях, которые организованы таким образом, чтобы выйти на контакт с человеком было невозможно. Вы можете сами вспомнить такие примеры у банков, авиакомпаний и других корпораций. При этом в других компаниях чат-боты выполняют понятную роль, отсекая типовые варианты проблем и маршрутизируя обращение к нужному специалисту, ценой не критичного раздражения потребителя. Если переформулировать описанное выше на языке систем, то каждая система, например, служба поддержки, входит как составная часть в надсистему, в данном случае это ИТ-компания. Результат работы подсистемы зависит от смежных подсистем, и является лишь аспектом результата работы надсистемы. И необходимо рассматривать проблемную ситуацию и возможные решения как в рамках конкретной подсистемы, так и в рамках объемлющей надсистемы. То же касается стейкхолдеров. В описанной ситуации для службы техподдержки ими являются клиенты компании в лице пользователей продукта и лиц, принимающих решение о его покупки, и это – разные лица со своими интересами; руководители подразделений компании – службы продаж и аккаунтинга, взаимодействующей с клиентами, служб разработки и тестирования, службы аналитиков и технических писателей, если они выделены отдельно; руководство компании; HR, которым надо решать задачу по набору новых сотрудников в техподдержку, а также самих сотрудников службы техподдержки: ведь если изменения будут такими, что они массово уволятся, то это заведомо понизит качество техподдержки, в чем бы оно не заключалось. - Кейс, который можно использовать в качестве опоры (обсуждали его с Дмитрием и согласились, что он среднего уровня сложности) Мария — частный предприниматель. Она предоставляет услуги догситтера — платный выгул и уход за чужими собаками. В подчинении у Марии ещё три человека. Мария сама ведёт соцсети своего бизнеса и общается с клиентами. Последнее время она часто сталкивается с жалобами клиентов на низкое качество услуг. Проблемы включают несвоевременные визиты, недостаточное внимание к питомцам и недостаточную коммуникацию с владельцами. Эти проблемы приводят к недовольству клиентов и угрозе репутации Марии. ### Определение домена проблемы по модели Кеневина - **Определение домена:** Complicated - **Обоснование:** Проблема с качеством услуг догситтеров включает несколько факторов, таких как профессионализм догситтеров, внутренние процессы и коммуникация с клиентами. Эти факторы известны и поддаются анализу, но требуют экспертного вмешательства для решения. ### Описание текущей ситуации Мария замечает, что нарастают проблемы, которые влияют на качество обслуживания клиентов. Вот как она описывает ситуацию: - **Негативные явления:** - **Несвоевременные визиты догситтеров:** догситтеры не всегда приходят в назначенное время, что вызывает неудобства для клиентов. - **Недостаточное внимание к питомцам:** клиенты жалуются на то, что их собакам уделяют недостаточно внимания, что влияет на благополучие питомцев. - **Плохая коммуникация с клиентами:** Недостаток информации о состоянии питомцев и деталях визитов догситтеров. - **Низкий уровень удовлетворённости клиентов:** Увеличение количества жалоб и снижение лояльности клиентов из-за ненадёжных услуг. **МЦ**: с моей точки зрения, это переписывание на бюрократическом языке краткого описания ситуации, оно ухудшает ясность и понимание, а не улучшает их. Вообще, если смотреть на этот кейс, то есть общий шаблон: если ты недоволен своими подчиненными, то подойди к зеркалу - и ту увидишь кто виноват. Зачем ты нанял таких людей? Впрочем, может, люди - хорошие, просто ты поставил их в такие условия. что они вынуждены бегать от одной собаки к другой, и у них нет времени уделить внимание. Или клиенты ждут индивидуального отношения. а ты построил типовой процесс. Но по-любому виноватый - в зеркале. И стейкхолдеры - догситтеры и клиенты, но это и так понятно из краткого описания. А вот отношения самих догситтеров к ситуации явно не хватает, и это - типичная ошибка из позиции начальника. На этом примере можно показать кейс про принципиальное изменение проблемы. Например, на первом шаге может быть сформулировано, что “догситтеры не пунктуальны и невнимательны к собакам”, а анализ может показать, что в целом с этим нормально, но клиенты ожидают русских догситтеров, потому что рассчитывают на индивидуальное отношение к питомцам, и хотят его догситтеру объяснить, а общение с мигрантами у них получается плохо. А если нанимать русских - экономика плохо сходится. И это - другая проблема, надо делать новое описание, а описание первой - остается как ценный опыт. [http://requirements.ru/lections_26](http://requirements.ru/lections_26) # Связи Up:: %% Каталог: `=this.file.folder` Prev:: Next:: СDate:: [[25-09-05]] <!-- Шаблонное выражение выполнено заранее --> # 📥 Inbox ## Обратные ссылки без упоминания ```dataview list from [[]] and !outgoing([[]]) ``` & updated for the last time : `=this.file.mtime` %%