Рамочные диаграммы процессов в арсенале аналитика
•Download as PPTX, PDF•
2 likes•2,173 views
Доклад Игоря Архипова на конференции Analyst Days-4, 17-18 апреля 2015 г., Минск www.analystdays.com
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (12)
Similar to Рамочные диаграммы процессов в арсенале аналитика
Similar to Рамочные диаграммы процессов в арсенале аналитика (20)
More from SQALab
More from SQALab (20)
Рамочные диаграммы процессов в арсенале аналитика
- 1. - Intentionally left blank -
- 2. 2 Photo: ucumari https://www.flickr.com/photos/18922711@N00/3407006702/ https://creativecommons.org/licenses/by/2.0/ С развитием организаций Обеспечивающие процессы тоже должны развиваться
- 3. Рамочные диаграммы процессов в арсенале аналитика Архипов Игорь http://ru.linkedin.com/in/igarkhipov
- 4. Давайте познакомимся • ИгорьАрхипов • Сертифицированныйаналитик(CBAP®) • 7летопытанадолжностяхсвязанныхс бизнесанализом
- 5. Слишком много процессных аналитиков говорят о потоковых диаграммах процессов (например BPMN) как об основных диаграммах в работе аналитика. На самом деле, куда лучше начинать работу с построения рамочных диаграмм; это принесёт больше пользы. – Пол Хармон
- 6. Что такое процесс? • Для термина «бизнес процесс» не придумали пока единого верного определения • И это хорошо – Потому что процесс, как модель части реального мира, это инструмент для работы – Который зависит от целей этой работы
- 7. «Процессная зона» Photo: Albaraa Mehdar https://www.flickr.com/photos/32506409@N02/4535775355/ https://creativecommons.org/licenses/by-nc/2.0/ Photo: Arrtem https://www.flickr.com/photos/32745559@N05/4317372044/ https://creativecommons.org/licenses/by-nc-sa/2.0/ Любой процесс : • Предполагает работу • Имеет результат – Измеримый, Повторимый, Важный • Имеет начало • Может иметь название вида «Действие- Объект»
- 8. CASE STUDY: • Представьте себе, что вы аналитик • Вы начинаете работать в новой организации (например, как консультант) • Ваша задача – выяснить, как тут всё работает и дать рекомендации, как сделать лучше. – В разрезе изучения процессов
- 10. С чего начать? Photo: Viviana Ga https://www.flickr.com/photos/26372492@N03/4660976050/ https://creativecommons.org/licenses/by-nc-sa/2.0/
- 11. Все процессы организации находятся под влиянием контекста организации и изменений этого контекста. Начните с контекста – ISO 9001:2015 DIS
- 12. • Определитедомен – Т.е.группупроцессов,вкоторойвыработаете • Определитесущественныедлявыполнения процессафакторы,которыевлияютна его способностьдостигатьожидаемогорезультата – Внешниеивнутренние • Чтобы: – Определитьсястерминологией – Свзаимосвязями – Сзаинтересованнымилицами Анализ контекста
- 13. • Интервьюсруководством/заказчиком – Какправило,свободное(нестандартизованное) • Анализположенийи политик • Анализорганизационнойструктуры • АнализEnterpriseProcessArchitecture Основные инструменты
- 14. CASE STUDY: Что мы получили?
- 15. Изучаем черное облако Результаты Действия Триггеры Ради чего? Как их получить? Что должно стрястись? Photo: Squiggle https://www.flickr.com/photos/32099449@N00/2861459880/ https://creativecommons.org/licenses/by-nc-sa/2.0/
- 16. Остановимся поподробнее. Результаты • Это не цели! – «Заказ отгружен» – результат – «Все заказы отгружаются в течение 2 часов» – цель (objective) • Результат достигается с помощью продуктов – Output vs Outcome • Результат потребляется стейкхолдером – Разные стейкхолдеры ждут разных результатов от одного процесса – Основные группы стейкхолдеров: • Клиенты (User) • Исполнители (Supplier) • Владельцы (Business)
- 17. Остановимся поподробнее. Действия • Действие должно производить конкретный, атомарный результат в рамках процесса • И быть разумного размера – Без «Процесс ответа на звонок состоит из взятия трубки и приветствия звонящего», пожалуйста – Хорошее правило - не опускаться ниже уровня рабочих инструкций
- 18. Остановимся поподробнее. Триггеры • Процесс идёт от триггера к результату через действия. • Триггерами могут быть: – Осознанное действие • Часто – результат другого процесса – Временное событие • Время пришло! Работайте, пожалуйста.. – Срабатывание правила • Результаты мониторинга
- 19. CASE STUDY: Что мы получили? Как превратить это в процессы? Триггеры Действия Результаты
- 20. • Поиск лида • Оценка лида • Регистрация лида • Подписание контракта • Регистрация заявки на обслуживание • Выезд мастера • Получение оплаты • Оценка качества сервиса • Корректировка сервисных услуг • Составление отчёта за период CASE STUDY: Давайте попробуем
- 21. CASE STUDY: Давайте попробуем
- 22. Дело в фишках! Photo: erink_photography https://www.flickr.com/photos/49268016@N04/5191993099/ https://creativecommons.org/licenses/by/2.0/
- 23. CASE STUDY: Пример на фишки Поиск лида Оценка лида Регистрация лида Подписание контракта Регистрация заявки от контрактора Выезд мастера Получение оплаты
- 24. И дело в арности! Photo: SantaRosa OLD SKOOL https://www.flickr.com/photos/93087247@N00/26604044/ https://creativecommons.org/licenses/by/2.0/
- 25. CASE STUDY: Пример на арность Поиск лида Оценка лида Регистрация лида Подписание контракта Регистрация заявки от контрактора Обработка заявки
- 26. Попробуем другой фреймворк? • Все знают SIPOC – Даже если не слышали такого слова Supplier – поставщик Input – вход Process – набор действий Output – выход Customer – потребитель
- 27. Итак, что у нас уже есть? • Есть костяк процесса – триггер, основные шаги, результат • Что забыли? – участников • Что забыли еще? – вариации В детали пока не лезем!
- 28. It’s a TRAC! • Алек Шарп* называет такой подход: TRAC = Triggers-Results-Activities-Cases • Вот мы и определили рамки процесса (оно же скоуп). Как это выглядит? * http://www.clariteq.com/about-alec.html - Типичная рамочная диаграмма процесса
- 29. Запишем алгоритм 1. Определиться с контекстом – Терминология – Стейкхолдеры 2. Выделить основные строительные блоки: – Триггеры – Действия – Результаты 3. Построить цепочки действий 4. Найти границы процессов 5. Определить участников и вариации
- 30. 6. Определить цели 7. Определить метрики 8. Определить поддерживающие механизмы – Но об этом позже Запишем алгоритм (optional)
- 31. Анализ проблемных зон Photo: Felinux - Cogito ergo boom! https://www.flickr.com/photos/11464033@N00/2544320411/ https://creativecommons.org/licenses/by-nc-sa/2.0/
- 32. Что можно сделать еще? Обратиться к Игорю I – inputs G – guidelines O – outputs R – resources Photo: https://film.list.co.uk/article/13592-igor/
- 33. IGOR
- 34. Enablers analysis Благодаря которым работает любой процесс - Дизайн - ИТ поддержка - Среда - Персонал - Политики - Контроль Photo: Jason Means https://www.flickr.com/photos/10996264@N00/1925794672/ https://creativecommons.org/licenses/by-nc-nd/2.0/
- 35. Контроль качества Дизайн ИТ поддержка Оборудование Персонал Политики Контроль CASE STUDY: Enablers analysis Регистрация заявки Выезд мастера Оказание сервиса Получение оплаты Подписание контракта
- 36. Дизайн ИТ поддержка и оборудование Персонал Политики Контроль - Детальные схемы процессов - Входы/выходы - Каскад процессов - Шаблоны документов - Рабочие инструкции - Распределение ответственности - ИТ инфраструктура - Функционал ИС - Интеграция систем - Структура данных - Режимы доступа - Безопасность - Аппаратура - Логистика - Орг.штатная структура - Требования к персоналу - Проф. сертификаты - Карьерный путь - Мотивация - Компенсации - Политика в области действия процесса - Бизнес-правила - Законодательство - Стандарты - Цели - KPI - Метрики - Факторы успеха - Риски CASE STUDY: Enablers analysis
- 37. Burlton hexagon Photo: H.C. Williams https://www.flickr.com/photos/12192989@N03/5443311888/ https://creativecommons.org/licenses/by/2.0/ Дизайн Политики (c) Roget T. Burlton. What’s in a Business Architecture . IRM UK Strategic IT Training Ltd. Контроль Персонал Персонал ИТ системы Оборудование
- 38. Сведём всё воедино! Photo: Thomas Hawk https://www.flickr.com/photos/51035555243@N01/323683917/ https://creativecommons.org/licenses/by-nc/2.0/
- 39. Выполнение заявки Триггеры Действия Результаты - Звонок клиента - Письмо от клиента Регистрация заявки Выезд мастера Оказание сервиса Получение оплаты - Заявка сохранена, - Сервис оказан, - Оплата получена Проблемы / Риски Цели Проблемы: - Несвоевременный сервис - Сервис низкого качества - Отказ от оплаты Риски: - Пропущенные заявки - Пробки на дорогах - Вывод сервисного обслуживания на безубыточность - Высокая удовлетворенность пользователей - 100% регистрация всех заявок Участники Поддержка Ограничения Метрики - Клиенты - Мастера - Водители (аутсорс) - Секретарь - Система регистрации и учета заявок - Фин.система - Срок у конкурентов 2 дня - Законы предметной области - % зарегистрированных заявок от выполненных - Время закрытия заявки - Удовлетворенность клиентов
- 40. • ISO 9001:2015 • Есть требования к управлению организацией, в том числе управлению: – Процессами – Персоналом – Оборудованием – Поставщиками/подрядчиками – Рисками – Лидерством – По показателям Сертификация системы менеджмента
- 41. Управляя процессами описанным выше образом, вы делаете это в соответствии с требованиями ISO 9001:2015*, следовательно – лучшими мировыми практиками *ISO/DIS 9001, Stage: 40.99
- 42. Заметьте • Мы еще не нарисовали ни одного swimlane’а и не построили ни одной EPC- цепочки • Но уже имеем на руках результаты • И надо этим пользоваться
- 43. Photo: Hey Paul https://www.flickr.com/photos/10775233@N00/63562115/ https://creativecommons.org/licenses/by/2.0/ Давайте просыпаться!..
- 44. … и приносить пользу бизнесу. Вместе с рамочными моделями. Спасибо за внимание Архипов Игорь http://www.linkedin.com/in/igarkhipov Ig.arkhipov@gmail.com
Editor's Notes
- Для бизнес процесса нет единого верного определения. Все, которые есть, либо слишком широкие, что попадает всё, либо весьма узкие. Я пишу процессы. Фига, у нас один по полгода делают, а него много в день Хочу оптимизировать процесс жизненного цикла приложения. Много процессов. Управлять как процессом не всегда рационально Бизнес процесс есть модель части реального мира. По сути - инструмент для работы. В зависимости от целей этой работы, масштаб того, что изучается как процесс, может и должен меняться. Это важно, потому что управлять как процессом можно почти всем.
- - есть некая «процессная зона» с мягкими границами: все элементы процесса должны быть взаимосвязаны (обмазаны одним «бизнес клеем») детализация не должна опускаться ниже уровня экспертизы исполнителей …в которой строятся процессы. - Проще говоря, всё, что попадает в эту зону, выгодно изучать как бизнес процесс. При этом существует структурный фреймворк, в который вписываются процессы. - он не даёт определить процессы, но помогает их описать. Бизнесу больше и не надо.
- Попробуем разобраться, как работать в этой процессной зоне на примере кейса – представьте себе, что вы аналитик, который начинает работать в новой организации (например, как консультант). Ваша задача – выяснить, как тут всё работает и дать рекомендации, как сделать лучше. Разумеется, в разрезе изучения процессов организации, благо это тема нашей беседы.
- Пока организация для нас выглядит вот так
- Организация находятся под влиянием контекста и изменений этого контекста. Следовательно и процессы Вообще ISO9001:2015 много говорит о новых вещах, в том числе контексте. И этот стандарт, например, ставит скоуп на третье месте. Сначала контекст, из него вытекают стейкхолдеры, затем определяется скоуп.
- частью какого домена организации процесс является в какую группу входит это даст понимание терминологии и связных областей
- Положения, политики, законы, бест-практисы. Например, придя в ИТ департамент без опыта работы в операциях ИТ, есть смысл почитать ITIL или ISO 20000, идя в финансы – основные правила вечедения бухучета и взаимоотношений между юрлицами и т.д. Не всегда все положения будут выполняться, но сам факт их понимания уже создаёт контекст КУЛЬТУРА является контекстом. Оргштатка, локации, логистика, языки. Дресскод. Если в вашей организации используется Enterprise Process Architecture – она как раз состоит из таких доменов
- из черного квадрата, которым была для нас организация, выделили ту черную область Аутсорс (HR, финансы) вне той системы, с которой нам работать (оптимизировать, внедрять или тиражировать). Мы выделили набор телодвижений в компании, которые как-то процессно связаны между собой. Возможно этот кусок и есть процесс. А может – их там много Или ни одного, т.е. мы промахнулись и отрезали часть более глобального процесса.
- - Дальше всё очень похоже на игру в лего.(click) - Сначала вы находим строительные блоки, из которых собирается процесс. - Для этого мы последовательно ищем ответы на следующие вопросы: Ради чего или зачем ведётся деятельность в черном облаке? (click) Таким образом, мы получаем строительный блок «Результаты» (click) Как они были получены? (click)Что должно произойти в компании, чтобы эти результаты получить? Так мы находим блоки «Действия» и «Точки принятия решений» (click) Что должно стрястись, чтобы эти действия начали выполняться? (click) Так мы находим последний блок – «Триггеры» (click) - На этом этапе рано задавать другие вопросы («Кто?», «Как?», «Где?», «Сколько?») – никогда этого не делайте! Утонете в деталях, не получив общей картины.
- - Отличать от цели. Цель достигается через множество результатов. - Клиентские результаты – нужно отличать ситуацию достижения результата и «предполагаемого достижения результата». Например, процесс доставки товара. Привезти коробку клиенту – с точки зрения логики, привезенная коробка есть факт достижения результата. С точки зрения клиента – только если в коробке находится то, что он заказывал, и оно доставлено в оговоренное время, может служить фактом достижения результата. Еще сложнее пример – поставка оборудования. Оборудование поставлено когда: 1) оно физически доставлено на склад клиента? 2) оно принято на баланс клиента? 3) оно внедрено в производственную цепочку клиента? Исполнители – часто (даже как правило) процессы не предполагают конкретных полезных результатов исполнителям. Тем не менее, у исполнителей есть своё понимание того, когда процесс закончен, и это важно. Если но не совпадает с мнением клиента – у нас проблема (как было сказано выше). Владельцы – результаты для них часто очень отдельны от клиента. Например, на клиента, обратившегося в колцентр, результат – исправленная проблема. Для руководства – результат – оценка в послеразговорном опроснике удовлетворенности. Помимо ответа на вопрос «что получает клиент?» мы должны найти ответ на вопрос «какие еще критерии должны быть достигнуты?» . Есть много разных подходов к выделению групп стейкхолдеров, можно использовать любой, главное использовать. Этот например взят из PRINCE2, свою классификацию предлагает BABOK, PMI и т.д. Попробуйте задавать вопрос «Кто будет расстроен, если процесс не будет выполнен как надо?» Тогда вы найдёте дополнительные заинтересованные стороны.
- Конкретный. Его можно определить, «пощупать». Если промежуточный результата размазан – скорее всего, вы пытаетесь разделить цельное действие. Атомарный. Результат нельзя разбить на составные части без излишнего повышения сложности понимания процесса или углубления на уровень деталей ниже текущей абстракции. Разумного размера. На уровне рабочих инструкций – SME тот, кто диктует правила и выбирает способы и шаги получения результата. Как правило (не всегда, но очень часто) попытки работы с задачами такого уровня как процессами заканчиваются не в пользу аналитика, т.к. аналитик (как правило) не несёт экспертных знаний по предметной области.
- Результат других процессов. Классическая цепочка конец-начало Таймер. Еженедельные, дневные, месячные, годовые активности, запланированные активности, привязанные с срокам (2 недели от получения заявки - отчет) и т.д. Бизнес-правила. Результаты мониторингов, например переход от event management в incident management в problem management.
- Теперь надо эти процессы из них получить. Как видите, чтобы построить процесс, мы выворачиваем ту цепочку, которую получили, отвечая на вопросы нашего исследования. Триггер запускает процесс, состоящий из действий и принятий решений, чтобы получить некий результат. Наша задача сейчас проработать ту же цепочку уже в этом порядке, чтобы выявить недостающие продукты (промежуточные), возможные альтернативы и т.д. На самом деле – это тема для отдельной беседы, как выявлять все строительные блоки. (click) Теперь, нам нужно собрать из этого процесс (click) Как это сделать? Мы говорим, что любой процесс запускается триггером, заканчивается продуктом и состоит из действий. Наша задача – определить порядок выполнения этих действий для получения результата и понять, сколько же в этой цепочке процессов.
- - Прежде, чем мы рассмотрим возможные способы, предлагаю вам попробовать самим. Перед вами результаты подобной сессии по выявлению строительных блоков – 10 активностей. Для простоты триггеры и результаты тут не указаны. Наша задача – предположить, сколько тут бизнес процессов, во сколько бизнес-процессов можно сложить эти активности так, чтобы с ними было полезно работать. Давайте 5 минут, потом сравним, у кого сколько получилось процессов.
- - Прежде, чем мы рассмотрим возможные способы, предлагаю вам попробовать самим. Перед вами результаты подобной сессии по выявлению строительных блоков – 10 активностей. Для простоты триггеры и результаты тут не указаны. Наша задача – предположить, сколько тут бизнес процессов, во сколько бизнес-процессов можно сложить эти активности так, чтобы с ними было полезно работать. Давайте 5 минут, потом сравним, у кого сколько получилось процессов.
- Фишка – она же маркер или токен. Нечто, что передаётся от одного действия другому в рамках контрольного потока, передавая эстафету на пути к результату. Основное правило тут – один процесс работает с одним токеном. Как только токен начинает превращаться, между шагами нужно искать процессный интерфейс, скорее всего тут два процесса. Давайте разбираться на примере.
- Помимо фишек, чтобы определить границы процесса, можно использовать понятие арности. Сколько экземпляров следующего шага может запустить один экземпляр текущего? Сколько нужно экземпляров предыдущего шага, чтобы запустить текущий? Посмотрим на примере.
- Давайте посмотрим, один найденный лид ведёт к одной оценке лида, которая в свою очередь ведёт к одной регистрации. Одна регистрация лида – к подписанию одного контракта. Дальше, интересно, один конракт вызывает получение N заявок по нему. Опа, связь 1 к 1 одному нарушена, следовательно, тут нужно искать границы процесса. Дальше, для каждой заявки – одна обработка заявки и т.д. (click!) Когда мы видим арность 1-к-1, это переход внутри процесса. Когда же арнсть встречается вида 1:* ; *:1 ; *:* = ищем процессные интерфейсы.
- Кто может быть потребителем? Клиент – да. Другой процесс? Тоже да! Кто может быть поставщиком? Партнёр – да. Другой процесс? Тоже да! В чем загвоздка? В арности! Проанализировав таким образом ряд процессов, которые являются взаимными поставщиками-потребителями, можно случайно обнаружить, что они работают с одним токеном и связаны входами-выходами как 1:1.. Подождите-ка, мы это уже видели пару слайдов назад! В остальном такой фреймворк работает очень даже хорошо. Особенно полезно его применять внутри процесса для анализа отдельных его шагов. Но нужно быть аккуратным и не закопаться слишком глубоко в детали – иначе потеряется общая картина и анализ выйдет кусочным.
- Есть костяк процесса: триггер – основные шаги – результат. Что мы забыли? Мы забыли участников. Добавляем их пока крупными мазками, не разбираясь в распределении ответственностей. Что забыли еще? Вариации хода процесса. Добавляем внешние факторы, которые могут повлиять на ход процесса. В сами реализации пока не лезем!
- Довольно известный консультант из, кажется, Канады, Алек Шарп называет такой подход: TRAC = Triggers-Results-Activities-Cases Вот мы и определили рамки процесса (оно же скоуп). Как это выглядит?(click) А вот пример из практики (click) – скоуп процесса массового оповещения.
- При этом, для определения границ нужно запомнить, что переходы 1:1 – как правило внутри процесса, переходы 1:M или M:M как правило – между процессами, момент замены токена как правило – место процессного интерфейса. Процесс начинается с события и заканчивается имеющим ценность результатом. Процесс состоит из шагов и точек принятия решения В процессе есть участники а идти он может по разному, в зависимости от внешних факторов Всё это вместе – скоуп процесса с которым можно работать. Вся эта работа как праивло итеративна. Сначала выявляется контекст. Value added результат этого этапа – определённый домен или группа процессов. Следующая итерация – выявление артефактов. Value added результат – из чего состоит деятельность внутри домена. Следующая итерация – рамочная диаграмма. Только потом строится концептуальная модель, где появляются лейны (дорожки) у тех, кто любит flowchart и BPMN. Добавленная ценность на этом этапе – распределение ответственности Следующие итерации – детальное моделирование. Тут появляются и все возможные варианты прохождения процесса (от наиболее популярных и вероятных к самым фантастических), и взаимодействие с системами и т.д. до тех пор, пока цель моделирования не будет достигнута.
- Что сделать полезно, но необязательно на данном этапе. Можно определиться с целям. Помните, мы с вами сравнивали их с результатами и решили, что это несколько разные вещи. Можно определить метрики. Это могут быть KPI для целей, метрики для процессов, индивидуальные перформанс индикаторы. И можно опредеить поддерживающие механизмы, про них мы очень подробно поговорим минут через 10. А пока давайте посмотрим на инструмент анализа проблемных зон, который применим на этом этапе и превносит дополнительную ценность в описание скоупа.
- Скоупинговая модель может служить для решения проблем в самом процессе без построения детальных схем Как это работает? Для каждого выделенного на уровне скоупа шага процесса выписываются списком важные/релевантные детали или сценарии. Для этих деталей – списком проблемы или риски, связанные с этими деталями. Для каждой проблемы/риска – списком лист to-do. На самом деле удобно работать с этим в виде таблицы. В чем прелесть такого подхода, результаты легко вывернуть нужным боком. Например, по стейкхолдерам – получите схему painchain+action plan для каждого стейкхолдера, берёте с собой и идёте продавать что вы там продаёте Или по проблемам – получите, кого она затрагивает, какую ценность не даёт получить и что с ней можно сделать. Сортируете по размеру недополучаемой из-за проблемы ценности и получаете план действий
- Обратиться к Игорю IGOR зародился в IDEF’е. (click) Должен признать, IDEF0 – это пример плохой нотации для анализа процессов (т.к. служит другим целям – функциональному анализу), но хорошего фреймворка для структуризации мыслей. I – inputs. С какой информацией или материалами работает процесс. Что может быть объектом анализа в этом домене? Источник входов, например, и как можно повлиять на него, чтобы изменилось качество входов, тем самым улучшив процесс. G – guidelines. Требования регулирующих органов, стандарты, законы. Повлиять мы на них в общем случае не можем, но принять во внимание (причем, желательно ДО имплементации процесса) – можем O – outputs. Выходы процесса в виде информации или продуктов/услуг. По сути, какую ценность должен принести процесс, чтобы его выход был необходим потребителю R – resources. Какие ресурсы необходимо привлечь для того, что процесс закрутился – персонал, расходные материалы, оборудование, ит-системы и т.д.
- Помещаем в центр процесс. Окружаем его взаимодействиями: входы и их генераторы, выходы и их потребители, законы и стандарты и выпустившие их органы, ресурсы или enablers. Если взаимодействие уже работает – помещаем зелёную точку рядом с ним и забываем. Если оно работает, но есть проблемы – желтую. Если взаимодействие нужно проработать – красную. Так формируется скоуп дальнейшей работы по оптимизации, автоматизации и т.д. Хорошо работает как дополнительный инструмент планирования.
- В английском языке есть слово enabler, грустно, но в русском его нет. Придётся использовать страшное слово-заглушку «деблокиратор» или «поддерживающий механизм». Деблокиратор – это то, что позволяет процессу работать. Дизайн. То, по какой логике работает процесс, его внутренняя структура. Информационные системы, автоматизирующие этот процесс. Environment. Сюда относится как оборудование (станки, механизмы), так и окружающая среда для реализации процесса. Здания, температура воздуха, задымленность, освещённость и т.д. Персонал. Сюда входит оценка количества и качества людей, необходимые навыки и знания. Политики. Для того, чтобы процесс работал, необходимы общие правила по которым он должен работать. Например, по ISO 10002 - сначала составляется политика обработки жалоб, потом детализируется процесс обработки жалоб. Контроль. Метрики процесса и KPI, в которые они собираются., для оценки эффективности и результаивности процесса. Что замечательно – для проработки любого деблокиратора, остальные не обязательны, их можно аналзировать в отрыве друг от друга. А обязательно что? Правильно, рамочная модель, без которой такой анализ был бы неэффективным, если не невозможным.
- Как это выглядит? Берём процесс, строим табличку, в которую выписываем области к анализу. Дальше углубляемся в те из них, которые нам интересны.
- Давайте посмотрим, что куда можно отнести.
- Гексагон Бёрлтона – это шесть факторов, изучение которых ответит на вопросы «Почему процесс работает так, как он работает» или «Что нужно, чтобы процесс заработал так, как нам хочется». Вот эти факторы (click) Эта модель похожа на модель деблокираторов, но нарезает их другими кусками: Орг.структура Намерения и Стратегия Политики и правила Человеческий капитал Обеспечивающие технологии Поддерживающая инфраструктура