Рассмотрим конкретный пример:
а) слайды 5:51:1-3 из "глобальной" презентации пятиуровневого Strategy and Tactic Tree всего TOC, в которых кратенько изложен механизм выбора процессов для последующего улучшения методами Lean или Six Sigma.
5:51:1 Отчет по причинамб) книжка Service Operation из ITIL version 3 размазывает этот же вопрос по многим и многим пунктам (поэтому цитировать нужно чуть ли не половину из почти 400 страниц этой книжки), в том числе:
Потребность: под давлением обстоятельств есть тенденция решать непосредственные проблемы, нежели тратить время на разрешение корневых причин.
Результат: Доступна база данных для старта эффективных программ улучшения.
Аргументы: когда зафиксирован симптом, а не корневая причина, корневая причина будет продолжать генерировать симптомы. Симптом -- это задержка, корневая причина -- повод для многих задержек. Рассмотрение задержек это хорошая стартовая точка для выяснения корневых причин. Попытка ответить на вопрос "Что явилось причиной для задержки?" будет вести во многих случаях к надуманным причинам (или даже хуже, к надуманным решениям) и поэтому сбивать анализ с пути. Путь к объективному ответу на вопрос: "Что является причиной задержек?" -- ответ на вопрос "Чего ждет это задание?". Такая форма причины может быть использована как стартовая точка для выяснения корневой причины.
Действия: Компания создает общий банк данных по причинам путем установления процедуры отчетности менеджеров заданий, для каждой задержки в задании -- чего это задание ждет.
5:51:2 Анализ причин задержки
Потребность: из-за структуры проекта (большинство заданий расположено на параллельных критической цепи путях) большинство задержек в заверешении заданий не приводят к задержке завершения проекта. Удаление корневых причин для задержек заданий, которые не вносят вклад в задержки проекта, имеет маленькое влияние на производительность Компании.
Результат: Выяснены главные причины задержки проектов.
Аргументы: Завершение проекта затрагивается только задержками, которые вносят вклад в наибольшее исчерпание буфера проекта. Поэтому причины, которые вызывают такие задержки, называются уместными причинами. Из-за высокой неопределенности в окружении проекта, задания, которые вызывают наибольшее исчерпание проектного буфера могут быть идентифицированы только после события (не только задания в критической цепи могут быть ответственны за наибольшее исчерпание). В большинстве случаев, это накопление задержек по всему пути делает задание наиболее вторгающимся в буфер проекта. Вывод: Причины для задержек должны непременно собираться для всех заданий. Когда задание идентифицировано как наиболее исчерпывающее буфер проекта, все причины (вдоль пути), которые накоплены в этом исчерпании могут быть выяснены как уместные причины.
Действия: Создать банк данных уместных причин и периодически его анализировать по Парето-анализу.
5:51:3 Выполнение проектов улучшения
Сводится к тому, что для каждой уместной причины при поддержке топ-менеджмента выполняется проект Lean или Six Sigma.
-- принципиально разводит инциденты (срыв сервиса) и проблемы (причины, вызывающие срывы сервиса) и требует разных процессов обработки инцидентов (немедленно наладить сервис) и проблем (сначала выяснить суть проблемы, а затем эту проблему решить).
-- требует вести (раздельные) базы данных инцидентов и проблем, тем не менее установливая между ними связи (какая проблема к каким инцидентам привела).
-- требует вести парето-анализ для проблем, которые ведут к большому количеству инцидентов и выполнить для главных проблем улучшения.
Есть ли тут общее? Есть ли тут паттерн? Конечно, есть (и даже не один паттерн, а целая их связка -- "паттерн паттернов"):
-- четкое разделение "инцидентов и проблем", "симптомов и причин", жесткое разделение процедур работы для них.
-- ведение учета (базы данных) отдельно для инцидентов и проблем.
-- регулярный поиск проблем для известных инцидентов -- путем анализа базы данных инцидентов
-- выделение "главных проблем" путем парето-анализа проблем, приведших к наибольшему числу инцидентов и выполнение улучшений только для них.
Этот паттерн и есть "мощная идея" -- практика, которая с разными вариациями используется в самых разных организационных системах.
Цели PraxOS -- найти и описать такие общие для многих организационных систем паттерны, сделав это описание совместимым с RDL из ISO 15926 (побочным результатом такого описания должна стать возможность совместной работы поддерживающих различные организационные системы организационных баз данных).
Обучение организаторов сводится тем самым не к обучению разным организационным системам (пару тысяч страниц ITIL, пару тысяч страниц книжек Голдратта, и так далее со всеми остановками), а к обучению много более компактному набору мощных организационных идей -- умению распознавать эти общие идеи в самых разных организационных системах (т.е. умению находить общий язык с адептами различных конкретных организационных систем) и умению применять эти общие идеи в условиях конкретной организации (т.е. умению создавать организационную систему, приспособленную к нуждам конкретной организации).
Вот теперь главный вопрос: в какой форме описывать такие мощные идеи, сиречь общие для многих организационных систем паттерны? В какой форме описывать антипаттерны (общие для многих организационных систем мощные разрушительные идеи, вредные паттерны)?
* * *
Очевидно, что форма записи таких общеорганизационных (общекультурных, good practices) паттернов существенно зависит от выбранной технологии организационного моделирования.
Так и представляешь себе какой-нибудь IDEF0XXL (в котором кроме добавки учетных регистров указываются еще и Потребность, и Результат (не Выход!), и Аргументы, и даже Контраргумент. Ибо то, что в IDEF0 сейчас -- это только Действия с их Входами, Выходами, Ресурсами и Нормами.