Модель деятельности. Формирование моделей процессов на среднем и нижнем уровне иерархии

Прежде чем начать выстраивать средний и нижний уровни модели деятельности, необходимо очень осмотрительно подойти к вопросу о выборе инструмента для моделирования процессов. Если для верхнего уровня модели деятельности можно использовать достаточно примитивные блок-схемы и по большому счету все равно, где их рисовать: в ARIS, в MS Visio или в PowerPoint, то для среднего и нижнего уровня ситуация намного сложнее. Здесь нужно учесть целый ряд факторов, в первую очередь - наглядность моделей, возможности по обеспечению их целостности и предполагаемые трудозатраты, как на первоначальное моделирование, так и на последующую адаптацию моделей к изменившимся условиям.

Немаловажным фактором также является корпоративная культура организации, для которой строится модель. Если организация склонна к четкому структурированию своей деятельности, и для нее жизненно важно поддерживать собственную систему регламентации на максимальном уровне детальности, целостности и непротиворечивости, может быть востребован мощный и дорогостоящий инструмент. Такой инструмент, который позволит не только отображать какие-то функции и процессы, но и хранить всю информацию об элементах модели и связях между ними в единой базе.

Ключевое слово здесь - детальность, ведь такая база и такой инструмент смогут окупить потраченные на них деньги и усилия, только начиная от нескольких сотен диаграмм. В роли мощного и дорогостоящего инструмента в крупных российских и не только корпорациях часто используют ARIS, кроме него также бывают востребованы Business Studio (наша отечественная разработка, в которой реализована единая база как надстройка над MS Visio) и Casewise Corporate Modeler (насколько известно автору, имеет прочные позиции только в телекоммуникационной сфере).

Если в организации делаются только первые шаги в области структурирования деятельности, или же у нее не так много процессов, которые требуют моделирования, использование мощного и дорого инструмента будет если уж и не совсем неоправданным, то, по крайней мере, преждевременным. Среди инструментов, подходящих для такого случая, особо выделяется Visio - продукт компании Microsoft, который она приобрела в свое время у независимого разработчика, и до сих пор не удосужилась переработать его объектную модель и довести функциональность до уровня вышеупомянутых дорогих и мощных инструментов. Несмотря на этот досадный факт, Visio как средство визуализации процессов очень удобен и, что немаловажно, широко распространен - его очень часто справедливо рассматривают как некое полезное дополнение к стандартному пакету приложений MS Office.

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

Речь пойдет о CASE-средствах - аналитических системах, предназначенных для проектирования и разработки программного обеспечения. Сюда можно отнести как ветеранов рынка, имеющих за плечами десятилетия использования (наиболее показательный представитель - BPWin и его последующие маркетинговые реинкарнации), так и относительно свежих представителей когорты BPM-систем, коим уже несть числа.

Ко всем этим прекрасным программным продуктам можно применить одну и ту же нелестную оценку - они не предназначены для моделирования деятельности как таковой, а нацелены именно на поддержку автоматизации. Соответственно, нарисованные в этих системах диаграммы не будут адекватно восприняты широкими массами трудящихся, поскольку эти самые широкие массы, мягко говоря, не жалуют технократов и их механистический взгляд на организацию. При этом не имеет принципиального значения, использует бизнес-аналитик в качестве языка моделирования доживающий свое IDEF, крепко стоящий на ногах и хорошо сбалансированный UML или же стремительно отодвигающий своих предшественников BPEL - все они не пригодны для бизнес-моделирования, ориентированного, не в последнюю очередь, на решение глобальных бизнес-задач. Их целесообразно применять на стыке между функциями бизнес-анализа и системного анализа, условно говоря - на этапе формирования функциональных требований к программному обеспечению и разработки ТЗ.

Вышеприведенные рассуждения и оценки, конечно же, обусловлены во многом собственным опытом автора, поэтому субъективны и, возможно, в свою очередь заслуживают критики. В дальнейших подразделах автор постарается изложить свой собственный взгляд на технику моделирования процессов в Visio, так же, разумеется, не претендующий ни на исключительность, ни на исчерпывающую полноту.