?

Log in

No account? Create an account
Лабораторный журнал -- Day [entries|friends|calendar]
Anatoly Levenchuk

[ website | Лабораторный журнал ]
[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

PraxOS и организационные системы [27 Mar 2008|12:22pm]
Все организационные системы (management frameworks) используют одни и те же мощные идеи, часто без их явного названия, при этом их объекты еще и называются по-другому. Более того, "патентованные" организационные системы еще и обращаются друг ко другу (например, TOC рассматривает себя как фокусирующий фреймворк к Lean и Six Sigms и требует немедленно создать команды, практикующие на предприятии одну из этих мощнейших дисциплин улучшения процессов -- другое дело, что выбирать процессы, которые нужно затем улучшать методами Lean или Six Sigma нужно именно методами TOC).

Рассмотрим конкретный пример:
а) слайды 5:51:1-3 из "глобальной" презентации пятиуровневого Strategy and Tactic Tree всего TOC, в которых кратенько изложен механизм выбора процессов для последующего улучшения методами Lean или Six Sigma.
5:51:1 Отчет по причинам

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

Результат: Доступна база данных для старта эффективных программ улучшения.

Аргументы: когда зафиксирован симптом, а не корневая причина, корневая причина будет продолжать генерировать симптомы. Симптом -- это задержка, корневая причина -- повод для многих задержек. Рассмотрение задержек это хорошая стартовая точка для выяснения корневых причин. Попытка ответить на вопрос "Что явилось причиной для задержки?" будет вести во многих случаях к надуманным причинам (или даже хуже, к надуманным решениям) и поэтому сбивать анализ с пути. Путь к объективному ответу на вопрос: "Что является причиной задержек?" -- ответ на вопрос "Чего ждет это задание?". Такая форма причины может быть использована как стартовая точка для выяснения корневой причины.

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

5:51:2 Анализ причин задержки

Потребность: из-за структуры проекта (большинство заданий расположено на параллельных критической цепи путях) большинство задержек в заверешении заданий не приводят к задержке завершения проекта. Удаление корневых причин для задержек заданий, которые не вносят вклад в задержки проекта, имеет маленькое влияние на производительность Компании.

Результат: Выяснены главные причины задержки проектов.

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

Действия: Создать банк данных уместных причин и периодически его анализировать по Парето-анализу.

5:51:3 Выполнение проектов улучшения

Сводится к тому, что для каждой уместной причины при поддержке топ-менеджмента выполняется проект Lean или Six Sigma.
б) книжка Service Operation из ITIL version 3 размазывает этот же вопрос по многим и многим пунктам (поэтому цитировать нужно чуть ли не половину из почти 400 страниц этой книжки), в том числе:
-- принципиально разводит инциденты (срыв сервиса) и проблемы (причины, вызывающие срывы сервиса) и требует разных процессов обработки инцидентов (немедленно наладить сервис) и проблем (сначала выяснить суть проблемы, а затем эту проблему решить).
-- требует вести (раздельные) базы данных инцидентов и проблем, тем не менее установливая между ними связи (какая проблема к каким инцидентам привела).
-- требует вести парето-анализ для проблем, которые ведут к большому количеству инцидентов и выполнить для главных проблем улучшения.

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

Этот паттерн и есть "мощная идея" -- практика, которая с разными вариациями используется в самых разных организационных системах.

Цели PraxOS -- найти и описать такие общие для многих организационных систем паттерны, сделав это описание совместимым с RDL из ISO 15926 (побочным результатом такого описания должна стать возможность совместной работы поддерживающих различные организационные системы организационных баз данных).

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

Вот теперь главный вопрос: в какой форме описывать такие мощные идеи, сиречь общие для многих организационных систем паттерны? В какой форме описывать антипаттерны (общие для многих организационных систем мощные разрушительные идеи, вредные паттерны)?
* * *
Очевидно, что форма записи таких общеорганизационных (общекультурных, good practices) паттернов существенно зависит от выбранной технологии организационного моделирования.

Так и представляешь себе какой-нибудь IDEF0XXL (в котором кроме добавки учетных регистров указываются еще и Потребность, и Результат (не Выход!), и Аргументы, и даже Контраргумент. Ибо то, что в IDEF0 сейчас -- это только Действия с их Входами, Выходами, Ресурсами и Нормами.
17 comments|post comment

Государство и право [27 Mar 2008|10:54pm]
С сегодняшнего круглого стола: каждая госкорпорация появлялась тогда, когда для реализации каких-то государственных хотелок было очень неудобно иметь существующие правовые ограничения. Эти ограничения снимались не для всех (т.е. правились не общие для всех законы), а именно для конкретной корпорации (т.е. для нее специальным законом вводилось исключение из правил).

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

Если это не государственная политика, то это такой эксперимент -- но каковы критерии его успешности? Когда нужно будет подвести итоги? Что нужно будет сделать с экспериментальными установками (корпорациями) в случае его успешности, неуспешности?
* * *
Из услышанных анекдотов: Внешэкономбанку (который сделали госкорпорацией для того, чтобы не терять полтора года на переход в акционерную форму) потребовалось сообщить уставный капитал. А у него нет ни Устава, ни капитала. Действительно, это ведь некоммерческий банк.
3 comments|post comment

navigation
[ viewing | March 27th, 2008 ]
[ go | previous day|next day ]