Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Categories:

Организационные системы ("управления", фреймворки, процессные рифмы, ноты)

Организационные системы (фреймворки, "управления" -- см. http://ailev.livejournal.com/560612.html) отличаются тем, что каждая из них неполна. Так, организационная система теории ограничений мало что говорит о том, как организовать расширенное предприятие, обеспечивающее жизненный цикл непрерывного производства (т.е. как организовать проектирование, строительство и эксплуатацию химзавода, например, так, чтобы стык между строительством и эксплуатацией был гладким и эксплуататоры при каждом ремонте не поминали проектировщиков и строителей). Теория ограничений поминает SLA (особенно в части больших штрафов за срыв сроков поставки), но не содержит особого анализа в этой области.

Сервисный подход включает в себя многие другие организационные системы в явном виде. Вот, например, процессные оргподсистемы из драфта CMMI-SVC:
Process Management
Organizational Innovation and Deployment (OID)
Organizational Process Definition (OPD)
Organizational Process Focus (OPF)
Organizational Process Performance (OPP)
Organizational Service Management (OSM)
Organizational Training (OT)
Project Management
Capacity and Availability Management (CAM)
Integrated Project Management (IPM)
Project Monitoring and Control (PMC)
Project Planning (PP)
Requirements Management (REQM)
Risk Management (RSKM)
Quantitative Project Management (QPM)
Service Continuity (SCON)
Supplier Agreement Management (SAM)
Service Establishment and Delivery
Incident and Request Management (IRM)
Service Delivery (SD)
Service System Development (SSD)
Service Transition (ST)
Support
Causal Analysis and Resolution (CAR)
Configuration Management (CM)
Decision Analysis and Resolution (DAR)
Measurement and Analysis (MA)
Problem Management (PRM)
Process and Product Quality Assurance (PPQA)
Понятно, что такие организационные системы будут требовать наличия "проектного управления", но не будут специфицировать, какую именно проектную организационную систему (вариант проектного "управления", фреймворка) необходимо взять -- PMI PMBoK(R), PRINCE2(R), TOC(R) или еще какую.

Основной проблемой многих оргсистем является то, что они пытаются процессно организовать коллаборацию, что теоретически невозможно. Процессно организуется только кооперация.

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

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

Это очень напоминает буриме: процессные рифмы заданы, но общий организационный результат совершенно непредсказуем, несмотря на "сертификацию соответствия" всем рифмам. Процессные рифмы -- это шаблоны некоторых действий, прежде всего предметно-неспецифических и кооперативных (работа с финансами, организация учета сервисов, планирование в мультипроектной организации и т.д.). Беда системописателей (и счастье людей в организации) в том, что коллаборация соединяет процессы весьма причудливым образом, что делает общую кооперацию трудновыразимой -- деятельность в целом это всегда "джаз", а сертификация проверяет только наличие "игры по нотам" для отдельных партий. Немудрено, что в этом джазе играющиеся строго по нотам партии регулярно портят всю музыку -- но и представить джаз, в котором 500 человек увлеченно импровизируют, даже не зная нотной грамоты, тоже трудно (хотя для трех или даже десяти человек это вполне можно представить).
Subscribe

  • Эскиз клубного AI-проекта

    Эскиз клуба создателей на базе продвинутых AI-агентов Когда-то в 2011 году я выступил с эскизом образовательного проекта,…

  • Для каких задач я жду "приличной RAG"

    Регулярно спрашивают, почему я сам работаю с LLM, но в наших курсах на Aisystant выставлена какая-то рудиментарная RAG реализация -- и я явно не…

  • lytdybr

    Опубликовано очередное обновление курса "Системная инженерия", в этой версии переписан раздел "5. Эволюционная архитектура". Уточнена терминология,…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 7 comments