2016-06-26: Инциденты в процессах - case management, а не побочные ветки
По мотивам поста будет выступление и обсуждение на IT Global Meetup в Питере 23.07 Готовьте кейсы для обсуждения!
Когда мы работаем над описанием какого-то процесса, то получаем много информации о всяких особых случаях, которые могут произойти. Их, естественно, тоже надо отметить в требованиях, и вот в диаграмме процесса возникает множество побочных ветвей, которые постепенно делают схему и прилагающееся к ней описание совершенно нечитаемым. Примерно тоже самое может произойти с описанием use case - множество побочных сценариев, которые тоже сделают use case неудобоваримым.
Происходит это потому, что мы забываем неявную предпосылку: процесс - это нормальное, соответствующее ожиданиям протекание деятельности. Как функционирование организма у здорового человека. А если в процессе этой деятельности возник особый случай, инцидент, и нормальное протекание нарушено, то мы имеем дело с совсем другим явлением, для которого есть свои практике управления - case management. И формат описания работы с кейсами - тоже другой. И если мы рассматриваем это таким образом, явно отделяя одно от другого, то описания процессов становятся сильно проще.
Это не означает, что в описании процесса - только один успешный сценарий. Но вопрос о том, где именно мы вываливаемся из процесса в кейсы - зависит от наших представлений о нормальном процессе. Возьмем обслуживание в магазине. Оплата наличными или карточкой - две понятные альтернативы, и они входят в основной процесс. А вот входит ли туда сторнирование уже пробитой позиции, зависит от того, насколько часто у вас ошибаются кассиры или насколько часто покупатели, узнав цену или общую сумму, отказываются от покупки на кассе. И если первое нам подконтрольно через совершенствование работы кассиров, то второе - нет. А еще есть интересный инцидент, когда покупатель смотрит чек и заявляет, что цена позиции выше, чем на ценнике в зале и требует продать по той цене, что была на ценнике.
Аналогично с обслуживанием покупателя в зале: рассматриваем ли мы обращение покупателя к продавцу как кейс или как начало процесса взаимодействия? В магазине обуви, где в зале выставлено ровно по одной паре каждой модели такое обращение за нужным размером - часть процесса. И он может быть сложен, если речь идет о большом магазине с отдельными кладовщиками - тогда он еще может требовать автоматизации, продавец делает запрос из зала и пока он идет до склада, кладовщик находит нужную пару, приостановив текущую работу. А может быть сделано по-другому, как во многих супермаркетах: продавец дает стандартный ответ, о том, что отсутствующее на полках - отсутствует в магазине, ищите сами. Ну и промежуточные варианты возможны.
Формат описания кейсов нам по факту хорошо знаком, хотя и мы можем и не догадываться об этом. Это регламенты работы службы поддержки. И даже если мы их не писали, мы можем хорошо их представить, сталкиваясь с ними с обоих сторон, например, при обращении в поддержку мобильного оператора. Или в гос.органы -работа с обращениями граждан - это тоже case management. Надо диагностировать ситуацию, а потом - разобраться с ней. Диагностика может быть многостадийной, тут дерево решений, и это - не процесс. А вот обработка части кейсов вполне может вызвать процессную с координированную работу специалистов, например, исправление выявленных ошибок с отражением в ранее сданной отчетности или замена сломанного оборудования на новое после того. как разбор кейса вывел на такое решение. Кстати, стандарты лечения, которыми руководствуются врачи, тоже устроены примерно таким образом. Они, кстати, доступны и с ними можно сверять действия вашего конкретного врача.
Если говорить об автоматизации, работе ИТ-аналитика, то с кейсами интересно следующая штука. Их много и они часто обладают достаточно большей динамикой, чем бизнес-процессы. Поэтому описывать их все в требованиях - бессмысленно. Однако на уровне автоматизации необходимо предусмотреть обеспечение необходимого взаимодействия. А еще - регистрацию кейсов и достаточное количества журналирования, чтобы можно было обеспечить процесс анализа и совершенствования процессов. Потому что если на каком-то процессе возникает слишком много кейсов определенного характера - надо учиться эффективно обрабатывать такие кейсы. Или перестроить процесс так, чтобы большого количества кейсов не возникала. Как в жизни: если у машины часто ломается подвеска, то надо знать, где ее быстро починить. А еще, может быть, аккуратнее ездить. Или сменить машину, чтобы подвеска новой была адекватнее вашему стилю вождения и вашим дорогам.
[ Хронологический вид ]Комментарии
Из комментариев Сергей Косовский: Огонь! Давно эта проблема у меня в голове висела! Спасибо за решение.
Из комментариев Эдуард Галиаскаров: Очень похожий подход я использую и студентам даю по use cases. А подсмотрел его у Арлоу и Нейдштадт в книге UML2 и унифицированный процесс. С другой стороны сам uml предлагает сворачивать каждый сценарий в отдельную деятельность.
Я: надо будет запомнить книгу
Еще обсуждения идут в группе Анализ в ИТ-проектах
Дополнение. При автоматизации важно предусмотреть в системе возможность зафиксировать результат разбора с кейсом-инцидентом. Например, если контрагент не согласен со стоимостью поставки и мы пошли на уступки - как это зафиксировать в системе? Это может быть отдельный документ о списании долга или возможность добавить скидку или изменить цену в старых накладных. Или если при проверке отчета обнаружена необходимость его исправить, при том, что документы нужным образом исправить нельзя. Впрочем, последний случай в принципе решается, если отчет можно экспортировать в Excel и исправить там - но хорошо бы, чтобы в системе оставались следы.
А регистрация и типизация инцидентов и автоматизация взаимодействия по ним - это уже следующий уровень.
Из поста на FB
В качестве ответа на статью Марк Мельник написал две статьи, в которых предлагаю термины, к которым мы более привычны: сценарий, типовой сценарий, рассматриваю ограничения нотации BPMN в моделировании сценариев. Там же я выдвигаю требования к ИС, которые хотелось бы видеть в реализации: https://habrahabr.ru/post/304242/ https://habrahabr.ru/post/305016/
Статьи интересные, мне понравились. На FB по ссылке можно посмотреть обсуждение.
Войдите, чтобы комментировать.