Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Categories:

Современные технологии организации -- итоги семинара по оргмоделированию (2)

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

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

Поскольку все эти экспертизы разорваны, то и адекватного интегрального инструментария для моделирования организации нет. Частные модели весьма развиты, а интегральной модели, которой могли бы пользоваться разные группы пользователей -- нет. А сложность оргмодели делает соответствующий софт трудоемким в его дизайне и программировании. Ну, а если нет массового дешевого софта -- то слабо развита и сама предметная область интегрального оргмоделирования.
* * *
В организации необходимо явно и всегда выделять две деятельности: организовывание и собственно работу. Это разделение используется многократно:

1. Процессы и проекты различаются тем, что в проекте организовывание проводится каждый раз, когда выполняется работа, а в процессе организовывание происходит однократно, а выполнение работы потом -- много раз. Отсюда и частое отождествление в процессных организациях слова "проекты" за "проектами организовывания" (проектами управления изменениями) процессов работ. Тут можно вспомнить и о программах -- они подразумевают процессы (т.е. повторяемость) в организовывании в отличие от разовых "организационных изменений". Скажем, у Голдратта его "процесс непрерывных улучшений" -- явная программа, ибо совершенно непонятно, куда и как долго идти и каковы будут "проекты". Тем самым легко разобраться с "поручениями", которые попадут либо в проекты (если их нужно один раз организовать и выполнить) или в процессы (если их выполнение нужно организовать только один раз, а затем они организованно выполняются).

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

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

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

Один из вариантов, как об этом разделении думать -- это как о разделении законодательной и исполнительной властей. Хотя все эти "разделения", как известно, шиты белыми нитками.

Еще можно выделить несколько "уровней организовывания": стратегический, операционный...
* * *
"Организационное звено", оргзвено -- это очень удачное название, много лучше "узла" и "подразделения". Мало того, что оно не так зависит от парадигмы одного отдельного коммерческого предприятия (не любое организационное звено -- это подразделение. Так, коллегиальные органы, или аутсорсеры, или предприятия какого-нибудь холдинга не являются подразделениями), так для меня в нем есть еще и прямой намек на сеть (часто также называемую "цепь" -- chain, а регулярно так и вообще chain network). Организация -- это всегда цепочка передач работы из рук/машин в руки/машины, работопроводящая сеть.
* * *
В подходе БИГ функции и процессы -- это во многом одно и то же. Функции мыслятся как "готовые к выполнению (то есть как-то уже организованные) процессы". Процессы мыслятся как "выполняемые". Функции -- это возможность выполнить операцию (без контекста "кому, что, когда и зачем"), процессы -- это проведение операций с учетом контекста "кому, что, когда и зачем". В принципе, отдельные операции могут быть группированы многими путями -- по "профессиям", по организационным звеньям (те самые функции), по развертке во времени (процессы). Думаю, это еще не все способы группировки. Сюда и нужно думать: как это так получается, что все операции ("функционал"), которые приписаны к разным организационным звеньям (оргструктуре), вдруг да склеиваются в правильную цепочку операций процесса или проекта. Тем самым "процессный подход" так же однобок, как функциональный или оргструктурный. Правильно было бы говорить о системном/деятельностном подходе: искать повторяющиеся паттерны в различных аспектах операций и их организации.
* * *
Операции в процессе связаны не бинарными отношениями "операция Б следует за операцией А". Это обычно тернарное отношение "операция Б берет на вход Нечто из выхода операции А". Дальше быстро выясняется, что эти отношения n-арны (нужно указать кто делает и кому передает и т.д.), аппетит в моделировании процесса приходит во время еды. Дальше весь вопрос, сколько вообще раз выполнится та или иная операция, и во сколько обойдется ее сбой -- это определит точность, с которой нужно моделировать. Тем не менее, залезать в процессы необходимо даже для сбора функций: чтобы определить реальную способность организации выполнять какую-то деятельность (т.е. производственную функцию), нужно копнуть много подробней, поразбираться в процессах.
* * *
Принцип открытой модели (он же -- инженерии знаний): моделируя, никогда заранее не знаешь, что тебе будет важным. Поэтому средства моделирования должны позволять моделировать жизнь как таковую, а не только организацию в предписанных заранее терминах. Отсюда важна качественная метаонтология и софт по ее поддержке.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 18 comments