Моделирование "процессов" в организации
Моделирование "процессов" (в кавычки я это слово взял намеренно) в организации -- вопрос предельно запутанный, ибо словом "процесс" обозначают множество самых разных организационных сущностей.
Задача моделирования "процессов" чаще всего появляется в следующих случаях:
а) "Чтобы было" -- (для отчетности инвесторам, в том числе формального доклада Совету Директоров), или для покупки сертификата серии 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. Таким подходом занимаются люди, придерживающиеся ситуационной инженерии методов: их задача описать используемый в организации метод работы (а не, например, административное подчинение работников, или последовательность нажатия кнопок и принятия отдельных решений в ходе пошагового выполнения четкой инструкции).
Когда вам поручают "моделировать процессы", поинтересуйтесь, какие именно "процессы" имеются ввиду, и какого сорта решения планируется принимать по этим моделям. Может, вам потребуется что-то одно из этого списка, а может, и все четыре (а то и больше -- ибо я привёл только основное из возможных вариантов).
Задача моделирования "процессов" чаще всего появляется в следующих случаях:
а) "Чтобы было" -- (для отчетности инвесторам, в том числе формального доклада Совету Директоров), или для покупки сертификата серии 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. Таким подходом занимаются люди, придерживающиеся ситуационной инженерии методов: их задача описать используемый в организации метод работы (а не, например, административное подчинение работников, или последовательность нажатия кнопок и принятия отдельных решений в ходе пошагового выполнения четкой инструкции).
Когда вам поручают "моделировать процессы", поинтересуйтесь, какие именно "процессы" имеются ввиду, и какого сорта решения планируется принимать по этим моделям. Может, вам потребуется что-то одно из этого списка, а может, и все четыре (а то и больше -- ибо я привёл только основное из возможных вариантов).