Русский
Русский
English
Статистика
Реклама

Анализ бизнес-процессов

Ваш звонок очень важен для нас как перестать разочаровываться в контакт-центрах и начать жить

15.03.2021 16:12:10 | Автор: admin
Как часто вы разочаровывались в контакт-центрах? Как это бывает, позвонили узнать о минимальном платеже по кредитке или выяснить, как разблокировать доступ в интернет-банк. Но сразу решить вопрос не удалось. Запутались в дебрях голосового меню. Поняли, что любая кнопка все равно приведет в никуда к замученному неправильным скриптом оператору. Ждали на линии первого освободившегося сотрудника. Затем 8 раз слушали Blue Da Ba Dee, когда он ставил звонок на удержание. В результате бросили трубку и запланировали поездку в офис банка.

Вы никогда не задумывались о том, почему в век мессенджеров люди пользуются голосовой связью? По данным Национальной ассоциации контактных центров (НАКЦ), в России за время пандемии 25% контакт-центров не зафиксировали уменьшения количества звонков, а 27% отметили рост объема обращений на 25%. Понятно, из-за COVID-19 у всех появилось больше поводов для беспокойства: Когда доставят мой заказ?, Что с моими ваучерами?, Вернут ли мне деньги?. Компании вкладывают сотни тысяч рублей в автоматизацию контакт-центров и обучение сотрудников, но что-то идет не так.

Возможно, проблема в подходе. Решения об автоматизации принимаются интуитивно, на основе наблюдений или методом научного тыка. Между тем в работе контакт-центра много неочевидных закономерностей, за которыми полезно наблюдать не в ручном режиме, а с применением технологий интеллектуального анализа бизнес-процессов (Process Intelligence). В информационных системах контакт-центров собирается много полезных данных блуждания клиентов по IVR (Interactive Voice Response), логи телефонных разговоров (время и длительность, с какого номера звонили) и др.

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

Немного статистики


По данным НАКЦ, сильнее всего на эффективность общения сотрудников контакт-центров с клиентами в условиях пандемии влияют:

  • базы знаний, которые устаревают или сложны в использовании,
  • нехватка операторов для обслуживания всех поступающих звонков,
  • недостаточное обучение сотрудников.

Как говорится в исследовании аналитического агентства iKS-Consulting, клиенты до сих пор предпочитают общаться с компанией по телефону. Правда, количество звонков в контакт-центры не растет. А вот сообщений по электронной почте, через чаты и мессенджеры становится больше на 2% ежегодно: их доля от общего количества обращений 20%. Роботы помогают клиентам не висеть долго на линии, а сотрудникам избежать монотонной обработки простых запросов. Но, несмотря на внедрение технологий искусственного интеллекта и роботизацию, пока в основном в контакт-центрах работают люди. Только они могут помочь клиентам решить сложный вопрос или разобраться в нетипичной ситуации. Более того, в век развития искусственного интеллекта (а также необходимости оставаться дома) эмпатия и живое общение становятся еще более ценными.

Например, до пандемии в Сбербанк поступало около 17 млн звонков в месяц и примерно 3 млн чатов. Половина клиентов получали помощь от ботов голосового на номере 900 и текстового в чатах. С апреля 2020 года каждый месяц банк получает до 23 млн звонков (+30%), а уже 60% всех вопросов решается в IVR.

Но так ли все прекрасно в работе контакт-центров в банках? По данным аналитического центра Национального агентства финансовых исследований (НАФИ), лояльность россиян к банкам снижается пятый год подряд. Своим банком, согласно последнему опросу, не удовлетворены 35,4% жителей страны. Они не порекомендуют его знакомым и, возможно, скоро найдут альтернативу.

Индекс NPS в динамике (2016-2020 гг.). Данные НАФИ

По оценке НАФИ, клиенты обращают больше всего внимания на стоимость счетов, депозитов, кредитов и качество обслуживания. Им важно быстро получать услуги и ощущать, что о них заботятся. Как полагают в НАФИ, в сознании клиентов банки все больше становятся обезличенными ИТ-сервисами и приложениями. А любой сервис сегодня должен быть быстрым, понятным и приятным в использовании.

Как добиться этого? Работу и людей, и технологий необходимо контролировать. В частности, собирать и анализировать данные об успехах и неудачах, чтобы с их помощью затем быстрее отвечать на вопросы о кредитах и быть для клиента палочкой-выручалочкой в любых нестандартных ситуациях.

Порочный круг IVR


IVR (Interactive Voice Response), или интерактивное голосовое меню, решает вроде бы благородные задачи:

  • по максимуму переводит клиентов на самообслуживание, чтобы снизить нагрузку на контакт-центр,
  • распределяет вызовы по нужным операторам.

Но почему клиенты часто недовольны голосовым меню? Приведем в пример несложный кейс с IVR:

Клиент звонит в банк выяснить, почему ему приходят подозрительные SMS-ки о попытке провести операции по его дебетовой карте. Блокировать ее он не хочет, ему важно сначала разобраться в ситуации. На звонок заранее записанным голосом отвечает IVR и предлагает прослушать голосовое меню: Добро пожаловать в Демьянкредитбанк. Для получения информации по адресам отделений и банкоматов нажмите 1. Для экстренной блокировки карты нажмите 2. Для получения пин-кода нажмите 0. Далее следует перечисление еще нескольких цифр, а затем тишина. В главном меню нет нужной ему цифры и пункта связаться с оператором. Он волнуется: прослушал меню, зашел в тупик, так и не решил вопрос. Чтобы связаться с оператором, нужно зайти в одну из веток, потом прослушать Оставайтесь на линии и дождитесь, когда вам ответит первый освободившийся сотрудник. А клиент-то уже на нервяке: у него с карты кто-то хочет списать деньги, а ему тут квест устраивают.

По данным IT-дистрибутора ICE Partners, людей больше всего раздражают длинные и сложные голосовые меню. Возможно, банку структура IVR кажется удобной и тщательно продуманной, но клиент может считать иначе.

На практике многим приходится бросать трубку, перезванивать в контакт-центр и снова прослушивать одну и ту же информацию. И даже тогда клиент не всегда может понять, что ему делать дальше.
Психолог Джордж Миллер, работавший на Bell Laboratories, в 1956 году установил, что человек способен удержать в кратковременной памяти от 5 до 9 элементов. Современные психологи снизили оценку объема кратковременной памяти до 4.
Кстати, все это лишний трафик 8-800, а в объемах крупной компании десятки тысяч долларов убытков в месяц. Кроме того, если после длинного и сложного IVR клиент не попадёт на нужного специалиста, то, скорее всего, он положит трубку и больше не вернется к этому банку. Поэтому лучше заранее проанализировать эффективность IVR, чтобы не раздражать людей. Как это сделать?

  • Один из самых простых вариантов позвонить в свою компанию. Это может быть познавательно. Так, можно прослушать IVR много раз, в частности, проверить, есть ли в конце выход на живого оператора. Затем удалить все лишнее, убрать зацикливания и тупиковые ветки меню.
  • Можно провести опрос своих сотрудников: насколько у них выросла или снизилась нагрузка с точки зрения ответов на самые простые вопросы, сколько раз за день им звонил один и тот же клиент, сколько вызовов они переводили на других специалистов и т.п.
  • Устроить опрос клиентов. Обычно после разговора с оператором включается система IVR (post-call опрос), в которой абоненту задаются 5-10 вопросов. Предлагается в баллах оценить качество обслуживания, уточнить, была ли решена проблема, посоветует ли он компанию своим близким и друзьям и т.п.


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

Так, в ABBYY Timeline можно загрузить логи систем, с которыми за определенный период работали сотрудники контакт-центра, например, логи систем IVR, коллтрекинга, базы знаний, CRM, а затем проанализировать разные показатели бизнес-процессов.
Логи это файлы, которые содержат все действия пользователя, совершенные в системе.
На основании этих логов система может как автоматически построить верхнеуровневую схему процесса,



так и показать детали по каждому конкретному случаю:





Допустим, это может быть путь клиента по веткам голосового меню, а также записи разговора с оператором и информация о том, какой вопрос пытались решить.

ABBYY Timeline помогает объединять данные логов, полученные из нескольких систем, и анализировать все составляющие процесса в едином пространстве. Все события, которые произошли в различных IT-системах, но относились к одному конкретному звонку, платформа объединяет в цепочку, которая называется маршрутом.

Каждый маршрут может быть уникальным, но ABBYY Timeline может легко находить в них закономерности или проверять различные гипотезы. Например, можно посмотреть, сколько времени у клиента занимает решение его вопроса в IVR. Сначала воспользуемся инструментом Запрос, чтобы отобрать те звонки, в которых клиент дошел до узла голосового меню, который не является промежуточным, а затем звонок был окончен.
Промежуточные узлы IVR это те, на которых от клиента ожидается некоторый выбор, и они не являются целевыми для клиента.

image

А теперь посмотрим статистику Длительность маршрута для отобранных звонков:

Самый долгий разговор занял 9 минут, а подавляющая часть звонков укладывалась в 3 минуты.

Этот показатель поможет определить, насколько проста и удобна навигация в меню для клиента. Если задача решается через IVR за 10 минут, а через оператора за минуту, то лучше переключать такой звонок на оператора. Автоматизированный информационный сервис не должен занимать у клиента больше 6 минут.

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

image

Теперь посмотрим нарушения этого регламента:
image
Можно не только отобрать звонки, которые нарушают время исполнения регламента, но и настроить автоматические уведомления по таким нарушениям. При появлении новых звонков, не укладывающихся в сроки обработки, ABBYY Timeline будет присылать email с прямыми ссылками на маршруты таких звонков.

Можно найти наиболее часто используемые ветки голосового меню, чтобы затем вынести их вперед:

image
Мы отобрали все звонки, которые закончились попаданием в целевой (не промежуточный) узел меню IVR и отобразили распределение звонков по имени узла IVR.

ABBYY Timeline позволяет измерить статистику брошенных трубок: на каких ветках IVR и сколько клиентов бросили трубку, не дойдя до конца. Это один из важных индикаторов проблем с IVR:

image
Запросом легко отобрать звонки, где между событием промежуточного пункта меню IVR и событием брошенной трубки не произошло ни одного события.

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

Контакт-центр может работать не только с историческими данными, но и проверять гипотезы. Инструменты прогнозирования в ABBYY Timeline позволяют смоделировать ситуацию, когда будущий клиент звонит вам и идет по лабиринту IVR. Если прогнать все возможные варианты действий, то вы обнаружите, где будет основной затык, и придумаете, как это исправить.

Вас много, а я одна


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

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

Задача специалистов, которые планируют количество сотрудников на линии, сделать так, чтобы клиент не ждал, а операторы не сидели без дела. Как добиться идеальных пропорций?

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

Еще один вариант проанализировать, как изменяется нагрузка на контакт-центр в режиме реального времени и какие узкие места есть в этом процессе. Например, можно воспользоваться инструментом Очереди в ABBYY Timeline и посмотреть, что по факту сейчас происходит с нагрузкой на линию:


ABBYY Timeline дает возможность отследить распределение заданий между командами обработки запросов в реальном времени. Картинка кликабельна

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


ABBYY Timeline вычисляет статистику простоев запросов в очередях. Картинка кликабельна


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

Есть показатели, которые говорят именно о качестве обслуживания. Например, клиента не должны переключать больше 5 раз на другого менеджера банка. Абонента гоняют туда-обратно и оставляют без ответа? Такую ситуацию можно отследить:

imageИнструмент Запрос использован для поиска маршрутов с множественными переадресациями.

Далее интересно посмотреть распределение таких звонков по конкретным сотрудникам, чтобы побеседовать с ними и, возможно, узнать что-то новое о вашем бизнес-процессе:


Картинка кликабельна

База, база, ответьте!


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

Кроме того, информация о банковских продуктах и услугах часто обновляется. Возникают новые кредиты, карты, счета, а времени на освоение нового немного. На помощь специалистам приходят базы знаний огромные интрасайты для сбора, структурирования, хранения и быстрого поиска необходимой информации. Но путь к ней может быть тернист. Особенно, когда материалы в базе переложили на новое место. Или когда нужных сведений просто еще не появилось. Кстати, вы знали, что в контакт-центре нельзя отвечать клиенту Не знаю?

Что происходит? Самый большой поток звонков в контакт-центр как раз бывает в тот момент, когда происходят массовые обновления, сбои, или, например, когда президент объявляет о кредитных каникулах для малого бизнеса. И банк накрывает валом звонков на эту тему, а в базе знаний дырка от бублика!

Что делает оператор? Ставит звонок на удержание и ищет ответы на вопросы. Спросит коллегу за соседним столом, старшего консультанта, напишет команде в чат. Тем временем количество и среднее время удержания обычно отслеживаются и не должны превышать, например, 2 минуты и 2 удержания за вызов. Иначе санкции и плакала премия. Хотя в данном случае не хватает просто Q&A по теме.

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

Как быть?
  • Многие контакт-центры предлагают самим клиентам доступ к своей базе знаний, и таким образом переводят часть абонентов на самообслуживание. Но есть нюансы: это не отменяет регулярного обновления базы и сбора недостающей информации по самым актуальным вопросам, по которым обращаются в контакт-центр.
  • Еще один вариант собирать данные о тематике самых долгих звонков, вводить информацию в Microsoft Excel и постепенно пополнять базу данных новыми темами.
  • Можно сделать удобнее: анализировать и повышать эффективность базы знаний с помощью современных/цифровых технологий или технологий анализа бизнес-процессов. Например, проанализировать, как обновление базы отражается на времени ожидания клиента.

Давайте посмотрим на список всех поисковых запросов, которые вводил сотрудник при работе с каким-то сложным и долгим звонком. Отберем самые длительные звонки:


Среди этих звонков найдем те, которые содержали более 3-х поисков по базе знаний:
image

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

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

imageСравнение двух запросов. В одном из них больше обращений к базе знаний.

Далее можно анализировать: по каким темам звонили люди, когда приходится долго искать ответ, чего не хватает сотрудникам (обучения или информации) и так далее.

Вместо заключения


Конкурентное преимущество любого контакт-центра качество обслуживания. А когда бизнес-процессы в компании налажены и совершенствуются в реальном времени, то ничто не мешает оператору четко и понятно отвечать клиенту, проявлять участие и заботу. А когда клиент доволен отношением к себе, он точно вернется к вам. И не так важно, что ему помогло в итоге: он быстро все нашел через IVR, оператор ответил на вопрос или клиент спросил голосового помощника. Важно то, что и сотрудник, и компания отнеслись к человеку и его ситуации неравнодушно.
Подробнее..

Дневник Производства 2.0 стартап в стартапе

16.11.2020 20:18:08 | Автор: admin
Что сложнее: запустить стартап-проект в чистом поле или встроить его в готовый продукт? На самом деле одинаково сложно все.

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

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

Хочу рассказать о том, как проходит запуск нового направления МоегоСклада Производство 2.0. С точки зрения бизнеса тема очень любопытна и интересна. Рассказываю в прямом эфире. Эта статья мой взгляд на результаты первых двух недель работы, поэтому смогу погрузить в костер событий и не упущу ни одной шутки.



Краткое содержание:

  • Мы
  • Откуда берутся бизнес-требования
  • Проектируем, предсказывая будущее
  • Производство гробов и модель данных
  • Как не сломить найти общий язык с бизнес-аналитиком, если ты архитектор
  • Мы проработали, но нет. Автомобиль и рыба. Что общего?

Компания МойСклад более 13 лет развивает и продает веб-сервис, упрощающий жизнь малому и среднему бизнесу. Сервис помогает вести складской учет, управлять продажами и закупками, печатать необходимые для ведения бизнеса документы и много-много всего. У нас налажен и постоянно развивается процесс разработки. Сделанные в первый день работы тикеты (на общепринятом языке задачи) могут уже завтра быть на проде. Продукт большой и сложный, пользователи активно делятся пожеланиями. Мы придумываем, как сделать полезный для людей сервис и делаем. И сейчас обновляем блок производства! Мы команда Производство.

Действующие лица первого этапа:

  • Аскар генеральный директор
  • Олег технический директор
  • Максим product owner, направляющий нас
  • Тимур бизнес-аналитик, который знает процессы производства
  • Максим тимлид команды разработки
  • Я системный аналитик

Вводная


Перескажу кратко вводную, которую в первый день спринта, 22 октября 2020-го, мы услышали от Аскара.

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



Длительное время отдел продаж и техническая поддержка транслировали жалобы и пожелания по улучшению производства от пользователей. Несмотря на наличие такой обратной связи, количество пользователей растет. Производство часто запускают в действующих организациях, которые уже ведут учет с МоимСкладом и не хотят менять его. Это одна из основных причин, по которым число пользователей текущего производства растет: работа с двумя программами вызывает негодование.

В феврале 2020 года в МойСклад написал Тимур (теперь уже наш бизнес-аналитик), работавший тогда с учетом на реальном производстве, с описанием как должно быть, прототипом и предложением о сотрудничестве. В итоге Аскаром принял решение подойти к развитию этого направления основательно и запустить Производство 2.0 обновленное и умное.

Займемся производством




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

МойСклад внутри большой и сложный, да и бизнес-требования изменчивы. Так что наша команда поставила себе на старте такие задачи:

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

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

Что помогло сделать первый шаг?


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

Рекомендация: перед проектированием системы изнутри, нарисуйте макеты пользовательского UI в любом виде, хоть карандашом на A4. Да, они 100 раз поменяются, и вообще нормальный UI/UX дизайнер потом все исправит, но они должны появиться, чтобы помочь.

На ней все держится. Модель данных


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

Если этот шаг не сделать на старте проекта, то есть шансы в какой-то момент открыть Америку или переделать все. Модель данных это что-то элементарнее фундамента, это Земля, а на ней держится вообще все.

Обсуждая первое приближение созданной модели на мозгоштурме, я сразу обозначила: представим, что мы делаем все и сразу (и вчера). Так, мы брали очередную сущность и выясняли что с ней может происходить, кто на нее может влиять, как ее можно поменять, как она влияет на учет, как она связана с текущими сущностями в системе, где связи могут появиться внезапно. Важно уметь задавать правильные вопросы.

В целом обсуждение было построено примерно так:

  1. Для очередной сущности я спрашиваю: Что это такое? и Что мы с этим можем сделать?.
  2. Тимур рассказывает нам о связанных процессах, показывает макеты, приводит примеры.
  3. Все задают много-много вопросов: А можно так?, А что, если...?, удивляются, и иногда кричат Так нельзя!.
  4. Тимур убеждает, что можно и очень надо.
  5. От примера про сборку шкафа мы переходим к примеру про гробы (А если мы производим гробы из австралийского дуба, и нам заказывают модификацию из сосны...).
  6. Смеемся, приходим к компромиссу, дорисовываем в модели данных связанные сущности, описываем ключевые параметры, оставляем заметки уточнить позже.
  7. Фиксируем в статье Вопросы и ответы решения по бизнес-требованиям и ограничениям, если они появились в процессе обсуждения или наоборот, если были сняты.

Логическую модель сделали. В итоге у нас получился такой вот небольшой монстр с заметками и облаками.



Рекомендация номер два. Если стартап запускается с нуля, то простор для творчества есть и можно брать любых опытных разработчиков с рынка труда. При создании стартапа в готовом продукте, команда должна хотя бы базово знать его, уметь исследовать и не бояться этого. Не запускайте на ранних этапах внутренние проекты с новыми людьми это может быть опасно для существующего продукта. Мы с Максимом ранее работали в других командах МоегоСклада. Для Максима роль тимлида это рост внутри компании. Мое назначение в МоемСкладе: исследовать все и везде. Поэтому вопросов у нас к Тимуру было много. Чем больше вопросов, тем больше ответов. Чем больше ответов, тем больше шансов получить более надежное решение.

Убей в себе архитектора и научись слышать


Немного о проблемах, которые возникают при проектировании. Из-за профессиональной деформации в первую неделю у нас было много недопонимания в команде: Разработка vs Бизнес. Я, со знанием проблемы, старалась меньше кричать о том, что мы не вписываемся в текущую архитектуру, но все же кричала. И Максим кричал.

Что разработчики хотят от бизнеса на ранних этапах? Уверенности! Мы много раз разбивали уверенность Тимура о скалы и уводили его от задуманных бизнес-требований к попыткам сделать из того, что есть, или сделать проще. Так нельзя!

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

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



Рекомендация номер три: разработчики от бизнеса ждут уверенности. Если вы бизнес-аналитик и представляете бизнес, или же вы бизнес-заказчик, будьте тверды в своих решениях до последнего, что бы разработчики не говорили. Проще не значит правильно! Если сделать проще сегодня, то завтра доработки выльются в очень большие суммы. Лучше потратить чуть больше в начале и вылить на своего разработчика всю душу (пожелания), чем потом страдать. Разработчик должен знать о потенциальном будущем!

Не откладывай на завтра. НИКОГДА!


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

Нам нужно было обсудить миграцию для текущих пользователей по ней было слишком много вопросов, а вести две версии производства вообще не хочется. И тут нашу командную уверенность опять опустили с небес на землю. Мы долго были в сомнениях по базовому бизнес-вопросу: а результатом производства по техкарте может быть более одного товара? Вроде, с бизнесом договорились уже, что результатом может быть только один товар.

Еще одна ошибка Мы знали, что надо было проверить на проде процент пользователей-разборщиков, но тянули до последнего, хотя уже даже SQL-запросы подготовили. Если на проде есть прототип и можно проверить теорию на реальных данных, проверять надо сразу!

Если бы я не писала, а говорила, то это звучало бы как (читать с выражением): М Ну Как бы сказать Короче Вот Каждый третий.

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



Из-за чего эта ситуация произошла? Мы все знали, что в текущем производстве такое возможно, но вести учет по таким техкартам проблематично. Несмотря на наличие примера про разборку автомобиля от Максима, нашего продакта, Тимур убедил: это редкий кейс и вообще таких пользователей мало. Олег был сразу против отказа от такой возможности. Именно по его подсказке мы, наконец, добрались до прода, чтобы проверить гипотезу. Да и я на этом демо архитектуры вспомнила про разборку рыбы на голову, хвост и филе.

В завершении первого спринта мы пришли-таки к окончательному решению, и уже совсем скоро наша модель данных позволит детально проектировать и начинать разработку. Макеты детализируются, подключаем коллег по тестированию и UI/UX. Продолжаем творить!

Итого


Чтобы успешно и быстро начать стартап-проект:

  1. Изучите весь известный бэклог, чтобы знать будущее.
  2. Выберите фундаментальную задачу, которая делает/меняет все.
  3. Для внутреннего стартапа нужно подключать команду с опытом решения других задач в развитии продукта.
  4. Слушайте бизнес и дайте вашему бизнес-аналитику эликсир уверенности. Бизнес-требования важнее системных ограничений. Системные ограничения всегда можно преодолеть (это точно)!
  5. Прежде чем что-либо проектировать, посмотрите на систему глазами пользователей нужны черновые макеты UI, которые обязательно будут изменены.
  6. Проектирование нужно начинать с модели данных
  7. Если есть возможность проверить теорию, проверяйте сразу, не откладывая до последнего.

О производстве в МоемСкладе
Подробнее..

Как корова помогла сделать интереснее процесс проектирования

24.11.2020 22:21:52 | Автор: admin
Всем привет! Я ведущий системный аналитик в компании МойСклад и сейчас мы с командой Производство запускаем внутренний стартап внутри стартапа Производство 2.0. Недавно я написала о том, с чего начать процесс разработки в новоиспеченном проекте, а сейчас хочу продолжить рассказ из горящего танка.

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

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



Нужно было переосмыслить бизнес-процессы, чтобы внести уточнения в модель данных и прототипы UI. Примеры про разборку рыбы и автомобиля мы применяли достаточно часто, но эмоционального фона диалогам они особо не придавали. Да и с учетом уточняющихся на ходу бизнес-требований команда устает уже после первого часа обсуждений. Нас пока мало от 4 до 6 человек на онлайн-встречах. Важно держать внимание, чтобы каждый участник был максимально вовлечен в процесс проектирования: разработчик и системный аналитик оценивают реализуемость, тестировщик помогает найти подводные камни, бизнес-аналитик и владельцы продукта помогают разбирать бизнес. Всеобщая концентрация может даваться тяжело, особенно, если транслирует экран и дорисовывает модели / дописывает требования только один человек.

Но все выглядит более ярко, когда в голову приходит интересный пример, пример, с коровой (обсуждения не имеют никакой связи с реальной жизнью участников команды, мы уважительно относимся к животным):
Так, давайте представим, что у нас мясной цех и мы разбираем корову.

Немного определений


Продукция товар, который был получен в результате выполнения заказа на производства.

Группа продукции это совокупность товаров (кортеж), который будет произведен в результате выполнения технологического процесса.

Ресурс товар, из которого производят продукцию.

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

Техпроцесс производства упорядоченная последовательность этапов, в результате выполнения которых производится продукция и затрачиваются ресурсы.

Техоперация документ, созданием и проведением которого пользователь инициирует одномоментное списание ресурсов со склада и зачисление готовой продукции на него.

Техкарта коровы


Ключевыми сущностями производства, от которых строятся все процессы, являются товар, этап, процесс и техкарта.

Нужно представить все возможные виды техкарт, которые мы можем получить. При производстве коровы.

Вариант 1: У меня есть мясной цех и луг. Я забираю корову с луга и за один этап превращаю ее в части. Это простая техкарта разборки.



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



Это простые техкарты, которые поддерживает текущее производство МоегоСклада. А теперь усложним.

Вариант 3: У меня есть мясной цех, упаковочный цех и луг. Я забираю 10 коров с луга. Сначала я превращаю 10 коров в очень много частей этап разборки, затем сортирую полученные части этап сортировки, а после помещаю в упаковки. Это все делается по сложной техкарте разборки коровы. Полученная техкарта:

Ресурсы: 1 корова, 100 м2 вакуумной упаковки.
Готовая продукция: 1 упакованная лопатка, 1 упакованная печень, упаковка на 2 стейка

Производственный процесс:

  1. Этап разборки (Ресурсы: 1 корова)
  2. Этап сортировки (Ресурсы: нет новых ресурсов, используются результаты этапа разборки)
  3. Этап упаковки (Ресурсы: 100 м2 вакуумной упаковки)

Получается, что я могу взять с луга как одну корову, так и 10, и 20 и т.д. И этот прекрасный вопрос бизнес-аналитику: Тимур, а можно произвести 1,5 коровы?. Истерика. Ответ: Можно. Мы же не только с коровами работаем, ограничения не ставим. Захотят пол коровы, возьмут половинку с луга или из морозильника.



Вариант 4: У меня есть мясной цех, завод по производству колокольчиков и луг. Мне привезли части коровы, я провожу этап сборки и получаю одну корову, которая не ходит. Делаем этап реанимации, производим для нее колокольчик и отправляем корову на луг. Это сложная техкарта процесса сборки коровы с колокольчиком.

Да, 1,5 коровы тоже допускаем.

Полученная техкарта:

Ресурсы: 1 упакованная лопатка, 1 упакованная печень, упаковка на 2 стейка, серебро.
Готовая продукция: 1 корова, 1 колокольчик.

Производственный процесс:

  1. Этап сборки (Ресурсы: 1 упакованная лопатка, 1 упакованная печень, упаковка на 2 стейка)
  2. Этап реанимации (Ресурсы: нет новых ресурсов, используются результаты этапа сборки)
  3. Этап производства колокольчика, может идти параллельно этапу реанимации (Ресурсы: серебро)
  4. Этап надевания колокольчика на корову (Ресурсы: нет новых ресурсов, используются результаты предыдущих этапов)



Такая модель помогла нам доопределить бизнес-правила и ограничения:

  • Можно ли в простой техкарте сборки установить норму готовой продукции 1?
  • Могут ли быть готовые продукты по результатам промежуточных этапов?
  • Можно ли задавать не целые нормы?

И много-много других.

И конечно, мы окончательно определились с кусочком монстра модели данных.

Техоперация и производственный процесс


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

Сейчас, имея только техкарты видов 1 и 2, мы можем резервировать корову или ее части на складе, используя заказ на производство. Чтобы списать корову со склада и превратить ее в части коровы или наоборот, мы создаем техоперацию. Заказ на производство ничего не зачисляет на склад.

Представим, что к нам пришел заказчик и попросил нас произвести для него части коровы. Мы, как производитель, регистрируем заказ на производство. В заказе на производство мы выбираем нужные части коровы.

Утверждения, вопросы и ответы:

Утверждение от бизнеса. Вы, как производитель, можете отслеживать процесс производства коровы поэтапно.

Вопрос. Могу ли я просто зарегистрировать, что было производство коровы, без контроля по этапам?

Ответ. Да, для этого вы используете техоперацию. Но если вам нужно резервировать перед этим части коровы, обязательно делаете заказ на производство коровы.

Вопрос. А что, если техкарта коровы создана на ногу, голову, стейк бедра и хвост, а заказать у нас хотят только ногу из этой техкарты?

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

Вопрос. А можно ли в заказе на производство донастроить техкарту так, чтобы в нем была только нога?

Ответ. Нет, тогда нужно создавать новую отдельную техкарту. Пример Техкарта Лопатки коровы

Вопрос. А можно ли в заказе на производство донастроить ресурсы из техкарты, увеличив количество коровы с 1 до 1,2 и добавить до ресурсы?

Ответ. Да, можно, потому что может быть брак, может приехать корова побольше и т.д.
И так далее.

Не для слабонервных

У меня была корова и я начал отпиливать от нее две ноги.





По итогам обсуждений были введены новые термины и определения в производстве мясной продукции:

  • Кортеж готовой продукции (коровы) неизменяемая группа готовой продукции, указанная в качестве результата производства по техкарте.
  • Сборка (коровы) процесс производства, в результате которого получается одна готовая продукция при любом количестве ресурсов.
  • Разборка (коровы) процесс производства, в результате которого получается более одной готовой продукции при любом количестве ресурсов.
  • Техоперация (над коровой) мгновенное производство в один этап.
  • Техпроцесс производства (коровы) поэтапное производство (приготовление) коровы
  • Проблематика коровы

В заключении


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

Гораздо интереснее разбирать бизнес-требования и проектировать не на типичных примерах, а на тех, которые могут заставить смеяться до слез.

Во-первых, это весело.

Во-вторых, это заставляет фантазию работать более креативно и извлекать из головы правильные вопросы.

В-третьих, все участники команды бодро подключаются к проектированию и придумывают свои версии производства.

Не будьте скучными и выбирайте примеры правильно!
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru