Итак, посмотрим на типовые задачи инжиниринга бизнес-процессов и организационного дизайна. Во-первых, обратим внимание на уровни представления, на уровни решения этих задач. В практике менеджмента сформировалось три уровня представления, три уровня иерархии представления деятельности предприятия. Это уровень предприятия в целом, уровень подразделений предприятия и уровень сотрудников предприятия. Поэтому наши задачи мы должны решать на уровне предприятия, на уровне подразделений и на уровне сотрудников. Хорошо. Что мы видим на уровне предприятия в целом? На уровне предприятия в целом мы должны представить цели, задачи, требования, которыми руководствуется предприятие в своей деятельности, продукты и услуги, которые производит предприятие. И под эти продукты и услуги мы строим корневую модель бизнес-процессов, которая обеспечивает представление производства продуктов и услуг. Поэтому на уровне предприятия — модели целей, модели задач, модели требований, модели бизнес-процессов. Еще один тип задач моделирования связан с моделированием участников деятельности — представление состава участников, организационной схемы участников деятельности и соединение участников деятельности с бизнес-процессами. Вот эти все представления, которые определяют цели, задачи, требования, продукты, корневые бизнес-процессы, участников деятельности и способы их соединения, вот это и есть корневые модели, базовые модели, которые мы используем при моделировании деятельности предприятия. Документы. Ведь модели — это способ, это метод, с помощью которого мы разрабатываем организационно-распорядительные документы и нормативные документы. Нормативные документы помогают участникам деятельности вести эту деятельность, показывают, как она устроена, показывают полезные методики и приемы ведения деятельности. А организационно-распорядительные документы являются документами прямого действия, и они предписывают, как нужно вести деятельность. Поэтому в качестве нормативно-методических документов можно назвать положение об архитектуре предприятия, положение об устройстве, положение об организационной структуре, положение о системе деятельности. В разных предприятиях этот документ может называться по-разному, но смысл его заключается в том, что он описывает в целом деятельность предприятия. И организационно-распорядительные документы, документы прямого действия: приказ о назначении генерального директора, приказы о назначении заместителей генерального директора, приказ о распределении обязанностей между заместителями генерального директора, ну и конечно, приказ об организационной структуре предприятия. Если коротко, то уровень предприятия, уровень представления системы менеджмента, организации процессов системы менеджмента на уровне предприятия выглядит примерно так. Уровень подразделений. Здесь все то, что на уровне предприятия описывается компактно, детализируется — детализируется до уровня подразделений. Поэтому как модели здесь используются функциональные модели декомпозиции корневых бизнес-процессов, процессные модели декомпозиции корневых бизнес-процессов, когда мы представляем действие в виде сети работ, сети активности, в виде потока активности. И модели функциональной либо процессной ответственности, которые определяют, кто за что отвечает. Если мы имеем такого типа модели, то есть мы описали подробно процессы, описали подробно организационную структуру и состав участников уже на уровне подразделений, мы закрепили ответственность участников на уровне подразделений, тогда мы можем составить нормативно-методические документы, которые определяют порядок исполнения бизнес-процессов, советуют нам, как исполнять бизнес-процессы. Это положение о бизнес-процессах на уровне подразделения. И мы можем разработать документы, организационно-распорядительные документы прямого действия, которые определяют порядок работы подразделений. В этих документах будут определены состав подразделений, задачи, которые решает подразделение, функции, которые решает подразделение в ходе ведения своей деятельности, место подразделения в системе корневых бизнес-процессов, порядок улучшения этого положения о подразделении. Уровень сотрудников. На уровне сотрудников эта же самая схема продолжает детализироваться. Процессы и функции доводятся до процедур, до описания действий, которые исполняются на уровне сотрудников. Положение о подразделениях превращается в положение о должностных инструкциях, то есть это порядки исполнения должностей, которые привлекаются и которые участвуют в исполнении бизнес-процессов. Ну а положение о бизнес-процессах здесь детализируется до положений о конкретных процедурах, в которых прописаны действия отдельных исполнителей. Если мы не прописываем действия исполнителей в виде процедуры, то мы их должны прописать в более агрегированном виде, в виде функций. Тогда положение о процедурах заменяется положением о функциях, о ролях, которые исполняют сотрудники при исполнении процессов, при ведении процедур. Вот эта схема разработки моделей и регламентов по уровням — уровень предприятия, уровень подразделений, уровень сотрудников, — она обычно разрабатывается или реализуется, проектируется методом сверху вниз — это один из способов проектирования. На первом уровне мы проектируем процессы деятельности, участников деятельности и соответствие их между собой на уровне предприятия и в тех моделях, которые мы применяем на уровне предприятия. На втором уровне мы определяем описание процессов, задач, которые решаются в этих процессах, функции, которые включены в эти процессы. Определяем состав участников, которые участвуют в процессах, исполняют процессы на уровне подразделений. И определяем соответствие между процессами и участниками. Ну и на третьем уровне мы ту же самую задачу решаем еще на более детализированном уровне — уже на уровне сотрудников, на уровне исполнителей, на уровне должностей. Процессы детализируем до функций или процедур, положения о подразделениях и состав участников детализируем до отдельных должностей или сотрудников и устанавливаем соответствие между ними. Схема довольно сложная — предприятия, подразделения, сотрудники, но иначе как вот вся эта большая система деятельности, которая называется предприятие и имеет уровневую структуру, как иначе она будет работать? Как иначе участники этого предприятия будут знать, что они делают, в каких процессах участвуют, какие у них права, какая ответственность, за что они отвечают? Проектирование таких схем может вестись либо по слоям, как мы это обсуждали на предыдущем слайде, либо может вестись методом колодцев. Метод колодцев предполагает следующее действие: на уровне предприятия в целом мы описываем корневую модель бизнес-процессов. Мы описываем основных участников деятельности в виде организационных блоков и заместителей руководителя предприятия, которые руководят этими блоками, определяем ответственность блоков за исполнение бизнес-процессов и дальше ведем разработку и проектирование процесса поштучно. Сначала мы берем процесс производства, декомпозируем этот процесс на уровень предприятия, на уровень подразделений и на уровень исполнителей. Устанавливаем соответствие исполнителей и процессов, разрабатываем документы, детализируем на уровне сотрудников, на уровне должностей. Устанавливаем соответствие процессов и участников деятельности, разрабатываем документы. Потом мы переходим к следующему процессу, например, продажи и поступаем точно так же. Вот таким последовательным перебором моделей корневых бизнес-процессов мы производим проектирование. Плюс такого проектирования в том, что одновременно мы имеем в виду ограниченную область деятельности компании. Тем самым мы задачи упрощаем. Но при этом мы каждое новое изменение должны интегрировать, должны консолидировать, должны гармонизировать с предыдущими решениями и с другими процессами, поскольку мы проектируем по процессу, то изменения в одном процессе приводят к необходимости изменений в других процессах, поскольку вся система деятельности предприятия работает как система процессов, как единая система процессов, а не как набор отдельных процессов. Поэтому здесь оптимизация за счет сокращения границ проектирования, а усложнение за счет итерационного характера, когда мы должны каждое новое изменение согласовывать с ранее произведенными действиями и с другими процессами.
