Скоупинг процессов в арсенале аналитика Too many process analysts talk as if flow diagrams, like BPMN, are the most important diagrams a business analyst can use. In fact, in most cases, a process analyst would be better advised to begin with a Scope Diagram, which will provide much more valuable information. http://www.bptrends.com/publicationfiles/advisor20121009.pdf
Об авторе Игорь Архипов CBAP Электронная коммерция Customer Services
Для бизнес процесса нет единого верного определения Часто процессом называют то, что является группой процессов Например, техническая поддержка. Еще чаще процессом называют процедуры (инструкции для отдельных шагов) Например, должностная инструкция инженера тех.поддержки Где же тут одиночный процесс? Для этого нет четких правил. Но есть «процессная зона» с мягкими границами все элементы процесса должны быть взаимосвязаны (обмазаны одним «бизнес клеем») детализация не должна опускаться ниже уровня экспертизы исполнителей
И это хорошо Бизнес процесс есть модель части реального мира По сути - инструмент для работы В зависимости от целей этой работы, масштаб того, что изучается как процесс, может и должен меняться
Но есть общий фреймворк …на котором строятся процессы Любой процесс имеет: начало триггер или событие, наступление которого запускает процесс финальный результат ради которого он существует. набор активностей и точек принятия решений которые обеспечивают получение результата.
Как определить процесс? Начните с домена Прежде чем приступать к анализу одного конкретного процесса, нужно определиться с контекстом – частью какого домена организации он является, в какую группу входит это даст понимание терминологии связных процессов стейкхолдеров. N.B.Если в организации есть Enterprise Process Architecture – она как раз состоит из таких доменов — Начинай сначала, — строго сказал Король, — и продолжай до тех пор, пока не дойдёшь до конца: тогда и остановись! «Алиса в стране чудес»
Что мы получили? Определив домен, мы условно выделили набор телодвижений в компании, которые как-то процессно связаны наверное Возможно этот кусок и есть процесс А может – их там много Или ни одного мы промахнулись и отрезали часть более глобального процесса
И как в этом разобраться? Поняв контекст, можно начинать разбираться с сущностями входящих в него процессов Смотрим, какие результаты этот набор телодвижений производит (зачем эти телодвижения нужны) Затем отвечаем на вопрос «Что должно произойти в компании, прежде чем мы «получим что-то»*» * «что-то» заменить на любой из результатов Таким образом мы находим необходимые шаги и точки принятия решений, которые приводят к выбранному результату Повторить N раз Потом ищем триггеры - события, по наступлении которых запускается деятельность Что должно стрястись, чтобы выявленные шаги начали выполняться? N.B. На этом этапе рано задавать другие вопросы («Кто?», «Как?», «Где?», «Сколько?») - можно утонуть у деталях, не получив общей картины
Результат – набор несвязанных пока артефактов Триггеры, действия, work products (пока не deliverables) Из которых состоят процессы Теперь надо эти процессы из них получить Не сложнее, чем «нарисовать сову»
Всё дело в фишках Фишка – она же маркер. Или токен. Один процесс = один токен. Как только токен начинает превращаться – ищем процессный интерфейс Например «Поиск лида» - «Оценка лида» - «Регистрация лида» - «Подписание контракта» – «Получение заявки от контрактора» - «Обработка заявки от контрактора» В том месте, где «лид» стал «контрактором», ищем интерфейс Замена токена = интерфейс, Преображение токена != интерфейс Например «Регистрация новой заявки» - «Оценка зарегистрированной заявки» - «Утверждение оцененной заявки»
И немного в арности Сколько экземпляров следующего шага может запустить один экземпляр текущего? Сколько нужно экземпляров предыдущего шага, чтобы запустить текущий? На нашем примере: «Поиск лида» - «Оценка лида» - «Регистрация лида» - «Подписание контракта» – «Получение заявки от контрактора» - «Обработка заявки от контрактора» Один найденный лид – одна оценка лида – одна регистрация лида – подписание одного контракта – получение N заявок по контракту. Для каждой заявки – одна обработка заявки и т.д. 1:1 = переход внутри процесса 1:* ; *:1 ; *:* = ищем процессные интерфейсы
Попробуем другой фреймворк? Все знают SIPOC Даже если не слышали такого слова Supplier – поставщик Input – вход Process – набор действий Output – выход Customer – потребитель
Пара мыслей о SIPOC’е Кто может быть потребителем? Клиент – да. Другой процесс? Тоже да! Кто может быть поставщиком? Партнёр – да. Другой процесс? Тоже да! В чем загвоздка? В арности! Проанализировав таким образом ряд процессов, которые являются взаимными поставщиками-потребителями, можно случайно обнаружить, что они работают с одним токеном и связаны входами-выходами как 1:1. oh wait… В остальном такой фреймворк работает очень даже хорошо. Единственный недостаток в терминологии. Общаться в терминах входы-выходы на непроизводственном предприятия – грустное дело. Тебя не понимают. В терминах «события – результаты» понимание находится быстрее. Почему – не знаю
Итак, что у нас уже есть? Есть костяк процесса: триггер – основные шаги – результат Что забыли? Участников. Добавляем их крупными мазками, не разбираясь в распределении ответственностей на этом этапе Что забыли еще? Вариации Добавляем внешние факторы, которые могут повлиять на ход процесса В сами реализации пока не лезем!
It’s a TRAC! Алек Шарп* называет такой подход: TRAC = Triggers-Results-Activities-Cases Вот мы и определили рамки процесса (оно же скоуп). Как это выглядит? * http://www.clariteq.com/about-alec.html
It’s a TRAC! - Типичная рамочная диаграмма процесса
Есть ли место итерациям? Неправильный вопрос - Нет места работе без итераций! Задача выявления и ограничения процесса может быть только итеративной. Сначала выявляется контекст. Value added результат – определённый домен или группа процессов Следующая итерация – выявление артефактов Value added результат – из чего состоит деятельность внутри домена Следующая итерация – рамочная диаграмма Только потом строится концептуальная модель, где появляются лейны (дорожки) у тех, кто любит flowchart и BPMN. Добавленная ценность на этом этапе – распределение ответственности Следующие итерации – детальное моделирование. Тут появляются и все возможные варианты прохождения процесса (от наиболее популярных и вероятных к самым фантастических), и взаимодействие с системами и т.д. до тех пор, пока цель моделирования не будет достигнута.
Пара промежуточных итогов Переходы 1:1 – как правило внутри процесса Переходы 1:M или M:M как правило – между процессами Момент замены токена как правило – место процессного интерфейса Процесс начинается с события Процесс заканчивается имеющим ценность результатом Процесс состоит из шагов и точек принятия решения В процессе есть участники Процесс может идти по-разному, в зависимости от внешних факторов Всё это вместе – скоуп процесса с которым можно работать
Если мы посмотрим с высоты …профессора Захмана, то всё, чем мы сейчас занимались, находится вот тут. И чуть чуть вот тут.
Почему это важно? Processes based on onthological structure will be predictable and produce repeatable results Processes without ontological structures are ad hoc, fixed and dependent on practitioner skills
Мы получили скоуп – что с ним можно делать? Несколько вариантов: Использовать как артефакт сам по себе Использовать как основу для дальнейшего анализа процесса Как артефакт, рамочная модель процесса позволяет: 1. Делать обзорные презентации 2. Бороться со scope creep в проектах 3. Выявлять заинтересованных лиц 4. Использовать общую терминологию 5. Строить дальнейшую коммуникацию и планировать действия Как базис для дальнейшего анализа, скоуп может быть использован по-разному. Посмотрим, какие есть техники, которые опираются только на модель, которую мы получили Использовать все эти техники одновременно, конечно, смысла нет.
Enablers analysis В английском языке есть слово enabler Грустно, но в русском его нет Давайте использовать страшное слово-заглушку «деблокиратор» Любой процесс работает благодаря этим деблокираторам . Они бывают внутренние и внешние по отношению к процессу. Внутренние деблокираторы: Дизайн. То, по какой логике работает процесс Все как правило копают сюда Информационные системы Или сюда Внешние деблокираторы: Персонал. Сюда входит оценка количества и качества людей, необходимые навыки и знания Политики. Для того, чтобы процесс работал, необходимы общие правила по которым он должен работать. Например, по ISO 10002 - сначала составляется политика обработки жалоб, потом детализируется процесс обработки жалоб. Контроль. Метрики процесса и KPI, в которые они собираются. Прочие элементы. (География, знание языков, оборудование и т.д.) Что замечательно – для проработки любого делокиратора, остальные не обязательны! А обязательно что? Правильно, рамочная модель – в ней есть вся необходимая информация для дальнейшей проработки остальных элементов!
Еще один хороший подход Который получил название Burlton’s hexagon* Он предлагает набор факторов, которые нужно изучить, чтобы ответить на вопрос «Почему процесс работает так, как он работает» или на вопрос «Что нужно, чтобы процесс заработал так, как нам хочется». Эта модель похожа на модель деблокираторов, но нарезает их другими кусками: - Орг.структура - Намерения и Стратегия - Политики и правила - Человеческий капитал - Обеспечивающие технологии - Поддерживающая инфраструктура *http://www.bptrends.com/about/advisors/roger-burlton/
Что еще можно сделать со скоупом? Обратиться к Игорю IGOR зародился в IDEF’е. Должен признать, IDEF0 – это пример плохой нотации но хорошего фреймворка I – inputs. С какой информацией или материалами работает процесс. Что может быть объектом анализа в этом домене? Источник входов, например, и как можно повлиять на него, чтобы изменилось качество входов, тем самым улучшив процесс. G – guidelines. Требования регулирующих органов, стандарты, законы. Повлиять мы на них в общем случае не можем, но принять во внимание (причем, желательно ДО имплементации процесса) – можем O – outputs. Выходы процесса в виде информации или продуктов/услуг. По сути, какую ценность должен принести процесс, чтобы его выход был необходим потребителю R – resources. Какие ресурсы необходимо привлечь для того, что процесс закрутился – персонал, расходные материалы, оборудование, ит-системы и т.д.
Issues analysis Скоупинговая модель может служить и для решения проблем в самом процессе без построения детальных схем Как это работает? Для каждого выделенного на уровне скоупа шага процесса выписываются списком важные/релевантные детали. Для этих деталей – списком релевантные проблемы. Для каждой проблемы – списком лист to-do. В чем прелесть такого подхода, результаты легко вывернуть нужным боком. Например, по стейкхолдерам – получите схему painchain+action plan для каждого стейкхолдера, берёте с собой и идёте продавать что вы там продаёте Или по проблемам – получите, кого она затрагивает, какую ценность не даёт получить и что с ней можно сделать. Сортируете по размеру недополучаемой из-за проблемы ценности и получаете план действий
Заметьте, мы еще нарисовали ни одного swimlane’а и не построили ни одной EPC- цепочки Но уже имеем на руках результаты И надо этим пользоваться
Приносите пользу бизнесу. Вместе с рамочными моделями. Спасибо, до свидания
Полезные ссылки Добавлю ссылки на статьи и книги, где можно подробнее прочитать обо всём, что было в докладе – в том числе на работы Alec Sharp, Roger Burlton, Paul Harmon, John Zachman