Окончание. Начало см. PC Week/RE, №42/2000, с. 44.

    

Как организовать работы по описанию бизнес-процессов и их реинжинирингу на российском предприятии?

Вопросы организации РБП, характерные для западной практики, подробно описаны в литературе [1-3]. Введение таких понятий-ролей, как владелец процесса (process owner), лидер команды (team leader), реинжиниринговая команда (reengineering team), коммуникатор (facilitator), участник команды (team member), внешний консультант (external consultant), координатор (coordinator), “царь” реинжиниринга (reengineering czar), контрольный комитет (steering committee) и др., для руководителей российских предприятий будет понятно в целом, если не затрагивать их существа и влияния на успех процесса реинжиниринга. Поэтому в дальнейшем мы рассмотрим, как организовать процесс на российском предприятии с выделением существенных ролей и наполнением их конкретным содержанием.

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

Поэтому целесообразной схемой организации работ представляется создание мобильной команды (подразделения), которая сосредоточится на методологии, программных средствах, описании и конструировании бизнес-процессов с последующей оценкой затрат и решением других задач, вытекающих из знания бизнес-процессов предприятия. Каков должен быть профессиональный состав участников образуемой команды? Проще всего дать ответ для банковской сферы: в команду могут войти бизнес-методисты, банковские технологи, сотрудники автоматизации, но заниматься они при этом будут не написанием программ и не постановкой задач на автоматизацию, а системотехнической работой по созданию банка данных бизнес-процессов. Численность такой команды может составлять 6-8 человек, не больше. В таком подразделении будет сосредоточена и команда реинжиниринга, и “царь” реинжиниринга (методология и инструментарий). Чего не хватает такой команде? Не хватает лидера реинжиниринга и хозяев бизнес-процессов. Лидер - один из высших менеджеров предприятия, имеющий полномочия принимать решения по кругу вопросов, входящих в РБП. Хозяин бизнес-процесса - менеджер, ответственный за отдельный бизнес-процесс предприятия. Например, для банка хозяевами являются руководители подразделений, отвечающих за кредитование, торговые операции, инкассацию, бюджет и т. д. Представляется целесообразным прямое подчинение команды реинжиниринга “лидеру”, если по рангу он выше “хозяев бизнес-процессов”. Именно позиция и возможности лидера могут сделать процесс внедрения РБП успешным и реальным. Так, первая фаза РБП - описание бизнес-процессов “как есть” - может пройти безболезненно и сразу дать значительные результаты. Ее реализация, скажем, в универсальном банке по всем бизнес-процессам с детальным уровнем описания (до элементарных процедур) занимает приблизительно год-полтора. Надо иметь в виду, что такое глобальное описание с нуля делается один раз, впоследствии же осуществляются только изменения в описании процессов. Такая система освобождает многих сотрудников от большого объема трудоемкой работы. При наличии банка данных бизнес-процессов, реализованного в современных СУБД, стоимостной анализ, перепроектирование организационной структуры, получение положений о подразделениях, должностных инструкций и нормативных документов из рутины превращается в творческое, аналитически направленное дело. Вопросы внедрения (разработки) информационных систем могут быть четко спланированы, оценены по целесообразности затрат и проконтролированы. А вот когда нужно переходить к фазе реструктуризации деятельности предприятия, от лидера требуется все мужество и политическая мудрость, и какие-либо рецепты здесь бессильны.

Инструментальные средства описания бизнес-процессов

Традиционно понятия “бизнес-процессы” и РБП связывают с CASE-технологиями (Computer Aided Software/System Engineering). CASE-инструменты и реализуемые ими методики структурного анализа представляют собой мощное средство проектирования бизнес-процессов. Имея практический опыт работы с CASE-средствами - ADW, System Architect, BPWin, - автор использует подход, который больше соответствует определению “базы знаний” (knowledge management, KM) с элементами “хранилища данных” (data warehouse, DWH). Возможно, CASE-средства - идеальный вариант проектирования, когда на завершающем этапе необходимо получить кодогенерацию прототипа информационной системы. Но много ли российских предприятий могут осуществлять разработки по столь дорогостоящему и труднореализуемому организационному пути? Наверное, такой подход оправдан для компаний, занимающихся разработкой информационных систем. Для промышленных предприятий и банков, чья цель не разработка, а приобретение на рынке систем, обладающих требуемой функциональностью по приемлемой цене, он вряд ли подойдет. Если использовать CASE-средства только для описания и проектирования бизнес-процессов, то можно получить много графических схем описания, однако с ними не очень удобно работать. Мы используем подход, когда бизнес-процессы хранятся в СУБД как “база знаний” предприятия. При этом информация структурируется таким образом, что позволяет получать различные представления бизнес-процессов в виде функциональной, организационной и информационной модели (сюда входит и документооборот) [3]; могут быть получены также внутренние нормативные документы, положения о подразделениях и должностные инструкции. Для графического отображения представлений можно использовать пакеты типа Visio или собственные встроенные графические средства программы. Кроме хранения бизнес-процессов в базе данных, предусматривается подкачка данных из транзакционных (OLTP) систем, количественно характеризующих параметры бизнес-процессов. Количественные параметры вместе с установленными нормативами дают возможность анализировать и планировать развитие процессов.

Коллективом специалистов спроектирована и реализована информационная система (СУБД Informix, архитектура клиент-сервер) для проектирования и моделирования бизнес-процессов и других задач, связанных с этим понятием; созданы справочники (для банков) типовых функций, направлений деятельности и продуктов, квалификационных требований и других категорий, позволяющих использовать их как готовые “базы знаний”; в стадии разработки находится “база знаний” типовых бизнес-процессов банка.

Суть подхода, реализованного в информационной системе, заключается в описании предметной области в понятиях (интуитивно опознаваемых), достаточных для структурированного представления объектов предметной области, связей между объектами и данных объектов и связей. При этом связи между объектами - это тоже объекты реляционной СУБД, а не связи самой СУБД между объектами. Все объекты модели имеют время жизни, т. е. учитывается хронология внесения изменений, что дает возможность проводить анализ в историческом разрезе. В разработанной модели между двумя объектами могут быть установлены множественные связи разных типов со своими данными по каждому из них. Совокупность объектов, связей и данных, определенных для конкретной предметной области, образуют модель предметной области. Такой подход позволяет через единое описание получать разнообразные схемы представления бизнес-процессов. При этом не ставится цели иметь на выходе данные для автоматического создания прототипа информационной системы. Инструмент скорее описывает предметную область в привычных понятиях, которые могут быть опознаваемы будущими пользователями информационной системы; он позволяет структурно описать и смоделировать проектируемый бизнес-процесс с позиций достаточности данных, оптимального документооборота, требуемых отчетов, оптимальности функций подразделений и конкретных ролей пользователей. Можно, например, ввести тестовые данные или наполнить реальными данными изучаемый процесс с тем, чтобы в него “поиграли” все задействованные сотрудники.

Краткое описание предлагаемого подхода к проектированию бизнес-процессов

На рисунке представлена принципиальная логическая схема модели бизнес-процессов. Схема отображает основные объекты, используемые для описания бизнес-процессов; соединительными линиями показаны связи (в том числе множественные) между объектами. Многие из объектов, указанных на рисунке, имеют иерархическую древовидную структуру.

К автору, консультанту в области управления, можно обратиться по телефону: (095) 108-0551.

Литература

1. Хаммер М., Чампи Дж. Реинжиниринг корпорации: Манифест революции в бизнесе/Пер. с англ. - СПб.: Изд-во СПбУ, 1997. - 332 с.

2. Робсон М., Уллах Ф. Практическое руководство по реинжинирингу бизнес-процессов/Пер. с англ. под ред. Н. Д. Эриашвили. - М.: Аудит, ЮНИТИ, 1977. - 224 с.

3. Шеер А.-В. Бизнес-процессы. Основные понятия. Теория. Методы: Изд. 2-е/Пер. с англ. ОАО “Весть”, ООО “МетаТехнология”, АОЗТ “Просветитель”, 1999.

Реинжиниринг бизнес-процессов

Краткая характеристика используемых объектов

1. Бизнес-процессы. Иерархический объект, хранящий описание всех бизнес-процессов предприятия; каждый процесс может быть рассмотрен как сам по себе, так и в составе более крупных процессов или через составляющие подпроцессы.

2. Нормативные документы. Описание всех внешних и внутренних нормативно-технологических документов, на основании которых осуществляются бизнес-процессы.

3. Функции. Объект, содержащий описание функций всего спектра производственной деятельности (для банка порядка 5000 позиций), из которых могут быть спроектированы законченные бизнес-процессы. Функции используются для формирования положений о подразделениях и должностных инструкций. Такой объект может служить типовым справочником (базой знаний) для предприятий одного типа.

4. Направление деятельности (продукты). Объект с описанием направлений деятельности и продуктов/услуг, производимых предприятием в рамках бизнес-процессов и с помощью функций/процедур.

5. Процедуры. Элементарные операции, образующие функции, являются индивидуальными для каждого предприятия. Используются при детальном описании бизнес-процессов.

6. Произвольная агрегация процедур. Объект, позволяющий осуществлять агрегацию процедур по произвольным принципам в отличие от объединения по функциям.

7. Окружение процедур. Группа объектов, детализирующих описание процедур по выбранному перечню описателей (бухгалтерская проводка, система коммуникаций и т. д.).

8. Организационная структура. Традиционная иерархическая структура предприятия с необходимыми характеристиками каждого элемента структуры.

9. Штатная должность. Объект, содержащий описание штатных должностей предприятия. Будучи связанным с оргструктурой, образует штатную расстановку.

10. Сотрудники. Объект с данными о сотрудниках предприятия.

11. Должность. Объект, содержащий описание типовых должностей предприятия.

12. Квалификационные требования. Объект, содержащий описание квалификационных требований предприятия к типовым и штатным должностям.

13. Рабочее место. Объект, группирующий процедуры для описания требуемых рабочих мест (ролей) предприятия; позволяет сформулировать требования к автоматизации процессов.

С помощью описанных объектов и механизма “путей анализа” по объектам, связям между объектами и данным объектов и связей могут быть построены разнообразные представления требуемой информации в табличном и графическом виде. Механизм “план-вариантов” позволяет работать с разными вариантами описания одного и того же объекта по принципу “старый”, “промежуточный”, “новый” и т. д.