?

Log in

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

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

Моделирование "процессов" в организации [04 Feb 2011|12:43pm]
Моделирование "процессов" (в кавычки я это слово взял намеренно) в организации -- вопрос предельно запутанный, ибо словом "процесс" обозначают множество самых разных организационных сущностей.

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

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

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

Существует множество архитектурных языков (UML/SysML, ArchiMate, MFESA) и множество "архитектурных фреймворков" (заранее заданных групп описаний -- Захмана, GERAM, TOGAF и т.д.). Опыт показывает, что все они не слишком адекватны:
а) группы описаний заставляют описать много лишнего, но не выявляют сущностного
б) языки это сущностное не позволяют выражать

Поэтому продолжается поиск "сущностного" в организации, и адекватных описаний этого "сущностного". В последнее время выявлено несколько таких "сущностностей":
1. Органиграмма как описание делёжки орг.ресурсов в терминах статичного административного подчинения. Отделы, службы и прочие подразделения. Споры начинаются уже в том месте, когда нужно описать место начальника подразделения (начальник представляет собой всё подразделение в дереве органиграммы, или только входит в него? Ответ загадочен при нескольких уровнях, в разных системах моделирования ответы на этот вопрос разные). Когда же речь заходит о проектных организациях, то "органиграмма" оказывается нужна разве что для выпуска приказов на уход в отпуск, но не для организации работ.
2. Структуры целей организации: например, Business motivation model (OMG BMM), или голдраттовское S&TT.
3. Правила работы (Business rules), например OMG SBVR. "Если клиенту за 60, и он клиент больше года, то выдать скидку 5% при любой покупке".
4. "Процессы".
5. Проекты.

Вот с "процессами" разберемся более подробно, ибо под этим словом все понимают разное.

1. Организационная суть "процессов" сводится к тому, что кто-то кому-то в организации всё время что-то поручает, а потом проверяет сделанное. И этот "кто-то" не является начальником, а смежником по производственной цепочке. Ежели к компанию поступил заказ, то он должен как-то пройти через всю компанию и вернуться в ту точку, где результат исполнения заказа будет выдан заказчику. Это моделируется как цепочка поручений работы, которая обязательно возращается (будь это внутренний "заказ", или "внешний", по письменному контракту, или без оного). Такой подход, основанный на теории коммуникативного действия (парадигмы речевых актов) позволяет моделировать "организационную сущность": кто что кому поручает, саму "организованность людей". Представителем такого подхода к "процессам" является DEMO ('Design & Engineering Methodology for Organizations -- http://www.demo.nl/), там есть стандарт представления информации, есть соответствующих софт моделирования. Кстати, в стандарте архитектурного моделирования OMG ArchiMate учитывается подход DEMO.

2. Поскольку организация должна выполнять разные функции (только не спрашивайте, как "конструкция" организации поддерживает эти "функции" -- это ведь и есть архитектура!), эти функции нужно задокументировать. Этим занимаются главным образом люди, проникнувшиеся ISO 9XXX и тамошнего понимания "процессов" как оргфункций. Проблема в том, что в оргфункциях нет даже времени, и функции -- это не работы ("конструкция"), это функции, и об этом забывают. На диаграммах IDEF0 (наиболее часто используемый стандарт изображения функций, раньше это называлось SADT) в верхнем левом углу рисуется не "самый первый шаг", а "самая важная функция на листе". То есть "процесса", как развертки времени, в IDEF0 нет.

3. Процесс, как развертка во времени из выполняемых шагов, или workflow ("ход работ", по-русски работы не "текут", а "идут" -- и "шагов потока", как часто получается в английском, поэтому нет). Это и есть BPM (business process management) -- IDEF3 в наиболее древней нотации, в России хорошо известна нотация EPC (event-driven process chain) из ARIS, а главным современным стандартом является BPMN 2.0, который поддерживают все "движки процессов". Каждую неделю очередная фирма заявляет о поддержке BPMN 2.0 моделирования, и компьютерного исполнения процессов, отмоделированных в BPMN 2.0.

4. Практики жизненного цикла (по-английски это иногда processes, а иногда practices). Развертка во времени тут -- это сам жизненный цикл (life cycle), понимаемый как "последовательность стадий", где каждая стадия соответствует примерной одинаковости состояния системы в ходе работ по ее инженерии (замысел, проектирование, сооружение, эксплуатация и т.д. -- хоть спички, хоть организации, хоть космодрома). А вот в ходе стадий выполняются те или иные практики, причем подробно не рассказывается, как их делать "шаг за шагом", зато указываются руководства, требования к квалификации сотрудников, выполняющих эти практики, нужный инструментарий, используемые языки и нотации представления информации. Именно из описания жизненного цикла можно узнать, используются ли в работе "итерации", или никаких итераций нет, и "возврат на доработку" -- это ЧП. Стандарты такого описания -- OMG SPEM, ISO 24744 и вновь разрабатываемый подход SEMAT. Таким подходом занимаются люди, придерживающиеся ситуационной инженерии методов: их задача описать используемый в организации метод работы (а не, например, административное подчинение работников, или последовательность нажатия кнопок и принятия отдельных решений в ходе пошагового выполнения четкой инструкции).

Когда вам поручают "моделировать процессы", поинтересуйтесь, какие именно "процессы" имеются ввиду, и какого сорта решения планируется принимать по этим моделям. Может, вам потребуется что-то одно из этого списка, а может, и все четыре (а то и больше -- ибо я привёл только основное из возможных вариантов).
5 comments|post comment

Об балеты, или танец 2.0 [04 Feb 2011|11:29pm]
Тот же tri7ki меня навёл на посмотреть несколько балетов -- современных, классических и промежуточных. И я с удивлением обнаружил, что классический балет смотреть уже не могу. То есть раньше немного смотрел, а теперь не могу.

В этом месте мне нужно заметить, что я довольно много лет "стоял у станка" -- то есть балет я знаю не только глазами, но ногами и руками тоже. Почти все мои преподаватели танца считали, что разминка должна быть обязательно из классического танца, а все движения разминки должны называться по-французски. Традиция-с.

И вот я понял, что современный балет (и даже не "балет", а "танец") я "понимаю", а классический (где движения до сих пор носят французские названия) мне принципиально стал скучен. До тоски скучен. Даже под музыку Pink Floyd с вкраплениями неклассических движений и нарочито антиклассических поз. Что толку от этих вкраплений, если балетный стиль остаётся? Бального, балетного, народного тацора -- их же просто по походке отличить можно!

А вот от современного танца я в восхищении (не от любого, конечно, но в среднем бОльше, чем от классики). Удовольствие наблюдается от самых разных стилей, даже если в них есть вкрапления того самого балета-от-станка. Ибо наличие принципиально иного "двигательного процессора" в современном танце даёт такой вкус и аромат к тем же battement tendu и rond de jamb par terre, что убийства интереса не происходит.

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

Современный балет -- это даже не десятка спортивных танцев в плане стилей. Это больше, это умение работать со стилем, как first class object. Это танец 2.0, где объектом творчества являются не столько сами движения и выражаемые при этом эмоции, сколько танцевальный (общедвигательный) стиль, выражающийся через эти движения и пропитывающий своим ароматом и цветом выражаемые эмоции.

Танцевальность современности -- это работа со стилями как языками (грамматиками и алфавитами), а не сочинение текстов (последовательностей движений) в рамках заданного языка. В новом интересном языке и самые простые тексты будут любопытны. В старом языке и самый сложный текст предсказуем и поэтому прост до неинтересности. Разные танцы в одном стиле становятся неразличимы: глаз смотрит уже не движения, а стиль. Ежели стиль знаком (а классический стиль более чем знаком), то глаз не различает в движениях первый акт балета и второй акт, и даже два разных балета не отличает друг от друга. Не на что смотреть, нечего изучать, внимание рассеяно. Хотя я подозреваю, что это верно только для зрителя 2.0. Зритель 1.0 прекрасно чувствует себя внутри стиля, ибо других стилей для него нет, он изучает тексты, а не языки. Зритель 2.0 уже не читатель, он лингвист. Язык танца -- это только для зрителя 1.0. Зритель 2.0 поинтересуется, какой именно язык имеется ввиду -- ведь их тысячи! Что касается танцоров, то в танце 2.0 проблема полиглотов. Я хорошо помню, как еще в средней школе нас тренировали первое отделение концерта танцевать строго по первой-третьей позиции (ибо в первом отделении был народный танец), а во втором отделении строго держать шестую позицию (ибо во втором отделении были бальные танцы). И как "народники" и "бальники" никак не могли переключиться -- их видно было за версту, кто откуда пришёл. В танцах 2.0 языков этих не два, и не три. И осваивать нужно не столько движения и их последовательности, сколько эти языки: где-то носочек нужно тянуть обязательно, а где-то он вообще не играет роли, но плечо обязательно поднимать вместе с рукой, что является грубейшей ошибкой там, где обязательно нужно тянуть носочек. Сознание должно при этом удерживать уже не последовательность движений: это само собой разумеется, не проблема. Сознание должно удерживать стиль. Для этого нужно вырасти до того, чтобы различать стили, выражать стили, говорить о стилях, сочинять стили.

А дальше будет танец 3.0.
7 comments|post comment

navigation
[ viewing | February 4th, 2011 ]
[ go | previous day|next day ]