Универсальный рецепт – реинжиниринг

Юрий Огурцов

        Промышленные предприятия и банки решают в основном две большие задачи (в зависимости от экономической ситуации в стране):

если экономика на подъеме и инвестиционный климат благоприятен, то развивают свой бизнес и расширяют направления деятельности;

если же наблюдается стагнация — занимаются реструктуризацией бизнеса, сокращая издержки.

        В первом случае план действий предприятия известен: составление бизнес-плана, привлечение инвесторов, развертывание нового бизнеса. Во втором случае дело обстоит сложнее, так как Россия не располагает особым опытом успешного реинжиниринга предприятий и к тому же эта работа обычно проводится за счет внутренних ресурсов компании. Во многом ситуация усугубляется тем, что для снижения издержек компании прибегают к сокращению штатов. Для средних и крупных фирм, знания о работе которых сосредоточены в головах сотрудников, увольнение приводит к потере важных корпоративных знаний и определенных направлений бизнеса. Примером могут служить крупнейшие российские банки, имевшие достаточно совершенные технологии. Расставшись после кризиса 17 августа со многими сотрудниками, они должны были предпринять значительные усилия для восстановления некоторых направлений бизнеса. В подобных случаях компании, не обладающие специальными технологиями, вынуждены будут повторять путь, пройденный раньше.
        При расширении бизнеса или появлении новых направлений организации часто сталкиваются с такой проблемой, как их оптимальное вписывание в сложившиеся технологические цепочки. Могут появиться дублирующиеся звенья и функции подразделений. Процесс создания технологии нового бизнес-процесса должен быть смоделирован и всесторонне проанализирован менеджерами до его практической реализации.

 Что дают бизнес-процессы и их реинжиниринг?

       Для того чтобы полноценно описать возможности реинжиниринга бизнес-процессов (РБП) и получаемые результаты применительно к западной практике, необходимо вводить такие понятия, как “миссия организации”, “корпоративная стратегия”, “стратегии по направлениям”, “цели организации”, “ключевые факторы успеха” и др. От их конкретного наполнения зависят формы РБП, применяемого для перехода организации от сегодняшнего состояния к завтрашнему и достижения поставленных целей. Очевидно, что в России говорить о таком “высшем пилотаже” преждевременно. Зато можно описать ряд практических задач, решаемых отечественными организациями, которые с введением понятия бизнес-процессов позволяют приблизиться к освоению метода РБП.
        1. Проектирование новой организационной структуры предприятия, составление штатного расписания и оценка затрат на реструктирование. При создании технологической модели предприятия “как есть”, т. е. при описании бизнес-процессов, реализующих их функций (единый справочник по предприятию), направлений деятельности/ продуктов (единый справочник по предприятию) и задач подразделений, необходимо использовать РБП.
        Проектируемая структура должна быть максимально приближена к бизнес-процессам, выполняемым предприятием. Ее звеньям назначаются функции, соответствующие требуемым направлениям деятельности (например, функции бухгалтерского учета — торговые операции банка: конверсия, межбанк, фондовый рынок). Поскольку функции входят в бизнес-процессы, при образовании новой единицы оргструктуры мы сразу видим, с какими из них они связаны. Если к функциям добавить количественные параметры, скажем, число операций, то оценить целесообразность процесса штатной расстановки будет легко. Если к штатным должностям привязать еще и данные по оплате труда, то можно планировать затраты (по расчетам с персоналом) в проектируемой структуре. Кроме этого, могут быть смоделированы этапы перехода от состояния “как есть” к состоянию “завтра” (спроектированы несколько структур) с планированием мероприятий по каждому этапу и функций подразделений на каждом этапе существования предприятия (Orgware).
        2. Разработка положений о подразделениях и должностных инструкций. Как это происходит на предприятиях? Подразделение управления персоналом раздает типовые формы документов, которые заполняются, согласуются и подписываются руководством. При этом в них требуется внести данные о целях, задачах и функциях подразделений, о функциях должностей сотрудников, которые руководители каждого подразделения определяют самостоятельно. Для крупных и средних предприятий количество документов по положениям и должностным инструкциям достигает нескольких сот. А какой анализ можно выполнить по этим бумажным документам? Практически никакого.
        Что дают бизнес-процессы в этом случае? Положения и инструкции разрабатываются на основе описанных выше процессов, функций, задач и направлений деятельности. А поскольку все будут использовать единые справочники, то вполне можно провести анализ по пересечению функций между подразделениями и должностями сотрудников, выполнить оптимизацию структуры, осуществить перемещение сотрудников, выявить упущенные функции и оценить последствия. Кроме того, сами положения и инструкции могут быть получены автоматически под проектируемую структуру.
        3. Ведение технологических карт и разработка нормативно-технологической документации (инструкций). По мере роста численности предприятия и расширения направлений деятельности усложняются цепочки взаимосвязей между подразделениями, увеличивается и усложняется документооборот, возникает стремление к обособлению функциональных подразделений и самоопределению функциональных обязанностей и ответственности. При сложных технологических процессах, как правило, просто некому взглянуть на все комплексно и предложить их оптимизацию и перераспределение функций сотрудников и подразделений. Чтобы упорядочить свои внутренние технологические процессы, предприятия разрабатывают набор нормативно-технологической документации, регламентирующей выполнение операций, зоны ответственности подразделений, проведение бухгалтерских транзакций. Это очень большая и объемная работа, которая возлагается на сами подразделения; численность нормативных документов обычно достигает нескольких сот. У данного подхода есть много недостатков, в частности такие:

• любой регламент — это в большей степени фрагмент некоторого целого бизнес-процесса, что отражает функциональную модель управления предприятием (пишу о том, что знаю и за что отвечаю), но не показывает его целостную технологическую модель;
• процесс внесения изменений в нормативные документы в связи с изменившимися требованиями внешних регулирующих инстанций или внутренними потребностями предприятия неудобен и требует времени при ручной переработке; если в разработке документа участвовало несколько подразделений, то процедура усложняется еще больше.

        При наличии базы данных бизнес-процессов можно получать регламентирующие документы автоматически. Все определяется степенью детализации описания процессов и полнотой взаимосвязей между ними. Если степень детализации доходит до описания бухгалтерских транзакций, то при необходимости можно очень легко вносить в базу данных изменения и получать обновленные технологические документы. Такая БД позволяет в любой момент видеть технологические карты процессов любой степени подробности с отражением документооборота, участвующих автоматизированных систем и функций сотрудников по каждому рабочему месту.
        4. Функционально-стоимостной анализ бизнеса компании. Любому руководителю крайне важно знать, сколько стоит бизнес компании, какую прибыль обеспечивают продукты и клиенты, каковы границы трансфертных цен внутри предприятия. Из данных финансового учета можно оценить прибыльность предприятия в целом, а если внутренний учет детализирован, то даже узнать доходы по продуктам. А вот как оценить, какие бизнес-процессы и продукты прибыльны, а какие нет? И здесь РБП помогает найти ответ. Поскольку бизнес-процессы состоят из функций, а функции привязаны к штатной расстановке, то через штатную должность можно выйти на оклад, определить стоимость рабочего места и выявить неоперационные затраты по бизнес-процессам. С другой стороны, в рамках бизнес-процесса реализуется один или несколько продуктов. Поэтому, определив по продуктам доходы, а по бизнес-процессу — расходы, мы будем в состоянии оценить прибыльность бизнес-процесса или группы продуктов. А включив в рассмотрение стоимость ресурсов, теперь мы достаточно достоверно построим систему, отслеживающую прибыльность продуктов, операций и уровень допустимых неоперационных затрат.
        5. Внедрение ИСУП и автоматизированных банковских систем. Некоторые российские компании внедрили или пытаются внедрить современные информационные системы управления ресурсами предприятия (ERP, Enterprise Resource Planning), которые призваны охватить все направления деятельности компании — управление финансами, учет, управление производством, снабжением, сбытом, учет затрат, управление персоналом. Выбор останавливается на самых совершенных западных системах — R/3, Baan, Oracle Application для крупных компаний, Syteline, MAX, Scala и т. д. — для средних. В связи с тем, что стоимость внедрения весьма значительна, закономерен вопрос: а будут ли ожидаемые результаты сравнимы с практическими? Если учесть, что оценка процесса внедрения обычно приводится в соотношении стоимость ПО/стоимость оборудования/стоимость консалтинга при внедрении и для систем R/3, Baan, Oracle Application варьируются в пределах 1/1—1,5/1—5 (при стоимости ПО $5000—$6000 за одно рабочее место, лицензия до 50 рабочих мест), то будет понятно, что задача минимизации рисков при внедрении весьма существенна.
        Процесс внедрения ИСУП в России обычно проходит по следующей схеме. Предприятие нанимает фирму, специализирующуюся в области ИТ и декларирующую опыт в такого рода деятельности. Можно поручить эту работу и своей собственной ИТ-команде. Однако в любом случае должны быть четко определены персональные требования предприятия к новой информационной системе и конечные цели ее внедрения. И здесь кроется большая проблема.
        Во-первых, крупной компании трудно самостоятельно сформировать интегрированные непротиворечивые требования к ИС для всего бизнеса. Можно получить отдельные пожелания от подразделений. Но как их интегрировать, как проанализировать на непротиворечивость и оптимальность бизнес-процессов? Каков должен быть уровень детализации описания, чтобы его однозначно можно было реализовать в информационной системе? Обычно на роль интеграторов претендуют крупные консалтинговые фирмы — “Артур Андерсен”, “Прайс Уотерхаус”, “Эрнст и Янг”, КПМГ, “Делойт и Туш”, “Юникон” и т. д. Безусловно, их специалисты являются высококвалифицированными профессионалами, однако стоимость услуг этих фирм вряд ли по карману многим российским предприятиям. А если учесть длительность процесса формирования единых интегрированных (увязанных и согласованных) требований предприятия, то задача становится непомерно дорогостоящей. Если же в процессе формирования требований необходимо выполнить элементы реинжиниринга корпорации с изменением организационной структуры, численности, функций подразделений, схем документооборота и т. д., то процесс усложняется еще больше. Между тем все это должно быть сделано до выбора и внедрения системы.
        Во-вторых, необходимо четко понимать, что все современные ИСУП — это настраиваемый инструмент, а не законченное решение. А чтобы настроить, опять же надо знать требования компании. Если внедрять систему, настроенную на какое-либо стандартное решение (референтные модели), то либо корпорации придется сильно менять структуру и функции подразделений, либо возможности системы не будут востребованы и инвестиции попросту потеряются. Кроме того, многие российские фирмы, занимающиеся внедрением ERP-систем, в большей степени понимают не требования заказчика, а саму информационную систему как инструмент параметризации и настройки. В лучшем случае они могут ответить на вопрос: “Как настроить систему?”, а не: “Что должна отражать система?”.
        Предлагаемый ниже подход и инструмент моделирования/проектирования бизнес-процессов позволит ответить на многие сложные вопросы, сократит лишние затраты при внедрении, поможет при формировании единых интегрированных требований корпорации. В результате это даст возможность сблизить “ожидаемый” и “практический” результат внедрения.
        6. Конструирование новых процессов и встраивание изменений в старые. Любая организация — это живой развивающийся организм, где постоянно приходится вносить изменения в работающие технологии или проектировать новые. Недостатки функциональной схемы управления в такой ситуации проявляются в полной мере: много времени занимает обсуждение вопроса, кто за что отвечает, назначение ответственного, распределение работ. При этом очень трудно избежать “узкофункционального” подхода, так как каждый участник имеет свой особый взгляд на задачу. В результате такого развития событий происходит напластование фрагментарных работ, которые с каждым разом повышают сложность системы. Можно привести пример, когда известная западная компания проводила анализ состояния информационных технологий крупнейшего российского банка. Вывод был такой: это сложнейшая система с множеством взаимосвязей между подсистемами, и они преклоняются перед нашими программистами, способными создавать такие шедевры, которые еще и работают. Понятно, что в данном случае сложность является недостатком, затрудняющим встраивание изменений и наращивание новых возможностей.
        Для того чтобы избежать автоматизации по подразделениям, необходимо отталкиваться от анализа бизнес-процессов с моделированием предполагаемых изменений, что и будет описано ниже.

Когда внедряется реинжиниринг бизнес-процессов?

        Если говорить о факторах, инициирующих процесс РБП, то не все примеры западной практики могут быть применимы в российских условиях. Для российской практики наиболее значимы:

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

        Расширение деятельности компании, как правило, связано с экстенсивными методами внедрения новаций — расширением оргструктуры, увеличением численности сотрудников, закупкой (разработкой) программного и аппаратного обеспечения и т. д. Но даже при очень успешном ходе бизнеса экстенсивный путь развития имеет предел. РБП позволяет организовать внедрение и дальнейшую поддержку новых технологий наиболее оптимальным способом с учетом масштабирования.
        Проведение РБП затрагивает многие аспекты деятельности компании: изменение оргструктуры, оптимизацию функций подразделений и сотрудников, перераспределение прав и обязанностей руководителей, изменение внутренних нормативных документов и технологии проведения операций, новые требования к автоматизации выполняемых процессов и т. д. Именно поэтому доминирующую роль здесь играет позиция первых лиц предприятия. Без их понимания и поддержки проекты внедрения РБП успешно завершены быть не могут. Как показывает западная практика, проектами РБП руководят первые лица компании, освобожденные от другой деятельности.

        Окончание следует

 

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

Бизнесменам суть бизнес-процесса (business process) интуитивно понятна, так как мышление в терминах производственных процессов — последовательной цепочки операций, приводящей к запланированному результату, — в общем-то свойственно разным категориям российских управленцев. Но существуют и точные формулировки этого определения.

Бизнес-процесс — это набор операций, которые, взятые вместе, создают результат, имеющий ценность для потребителя, — например, разработку нового продукта [1].

Бизнес-процесс — это поток работы, переходящий от одного человека к другому, а для больших процессов, вероятно, от одного отдела к другому [2].

Таким образом, бизнес-процесс — это поток работы, у которого есть начало, конец и границы. Он может быть описан с разной степенью детализации.
Существуют ли стандартные перечни бизнес-процессов? Есть мнение [1], что не существуют, потому что все предприятия уникальны и должны разрабатывать свои бизнес-процессы. Но это не совсем так, поскольку часто операции (например в банковской сфере) жестко регламентируются нормативными документами. Кроме того, современные системы управления ресурсами предприятия (R/3, Baan, Oracle Application и др.) предоставляют наборы “референтных моделей”, описывающих бизнес-процессы для разных типов производств и осуществляющих настройку систем в зависимости от выбранной модели. На наш взгляд, типовые бизнес-процессы имеют право на жизнь, мало этого, при развитии нового вида деятельности они могут существенно сократить время на осознание, проектирование и реализацию новой технологии. Затем предприятие может отойти от типового процесса, внеся в проект свою специфику.
Ключевая идея использования бизнес-процессов — интеграция базовых операций в единое целое. Другая, не менее важная идея — контроль за выполнением отдельного процесса и ответственность за его результат. Сегодняшняя практика такова, что менеджеры заняты улучшением функциональной структуры, а не описанием/перепроектированием самих процессов. Подход, проповедуемый основоположниками реинжиниринга, заключается в том, что вся деятельность компании должна быть организована вокруг бизнес-процессов.
Немного переиначивая М. Хаммера и Дж. Чампи, можно сказать, что не товары/ услуги, а процессы их создания приносят компаниям долгосрочный успех.
Реинжиниринг бизнес-процессов (РБП; Business Process Reengineering, BPR) относится к классу методов управления. РБП не заменяет других методов управления, но в силу его мощности в настоящее время широко используется в практике зарубежного менеджмента. Применение РБП позволяет по-иному взглянуть на процессы, обеспечивающие деятельность компании, сделать управление бизнес-процессами (Business Process Management, BPM) понятным, прозрачным и адекватным в быстро меняющейся ситуации. РБП направлен, с одной стороны, на улучшение качества обслуживания клиентов, а с другой — на перестройку внутренних процессов компании для повышения эффективности деятельности.
Существуют достаточно радикальные определения понятия РБП. Например: реинжиниринг бизнес-процессов — это создание абсолютно новых и эффективных бизнес-процессов без учета того, что было раньше [2]. Данное определение основано на том, что, привыкая к имеющейся технологии, сотрудники считают сложившееся положение нормальным и незыблемым. Проведение РБП предполагает, что все подлежит пересмотру и изменению, нет ничего неизменного. Такое понимание РБП диктует вполне определенные требования к команде людей, которым будет поручено заниматься реинжинирингом. Можно найти и другое определение: реинжиниринг есть фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения существенных улучшений в таких ключевых для современного бизнеса показателях результативности, как затраты, качество, уровень обслуживания и оперативность [1].
Заметим, что РБП — отнюдь не панацея, не единственный метод проведения изменений в компании, поэтому мы и описываем задачи и инструмент, позволяющий решать практические задачи.

Литература

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

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

 Юрий Огурцов

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

        Вопросы организации РБП, характерные для западной практики, подробно описаны в литературе [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.Окончание. Начало см. PC Week/RE, № 42/2000, с. 44.

 

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

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

2. Нормативные документы. Описание всех внешних и внутренних нормативно-технологических документов, на основании которых осуществляются бизнес-процессы.
3. Функции. Объект, содержащий описание функций всего спектра производственной деятельности (для банка порядка 5000 позиций), из которых могут быть спроектированы законченные бизнес-процессы. Функции используются для формирования положений о подразделениях и должностных инструкций. Такой объект может служить типовым справочником (базой знаний) для предприятий одного типа.
4. Направление деятельности (продукты). Объект с описанием направлений деятельности и продуктов/услуг, производимых предприятием в рамках бизнес-процессов и с помощью функций/процедур.
5. Процедуры. Элементарные операции, образующие функции, являются индивидуальными для каждого предприятия. Используются при детальном описании бизнес-процессов.
6. Произвольная агрегация процедур. Объект, позволяющий осуществлять агрегацию процедур по произвольным принципам в отличие от объединения по функциям.
7. Окружение процедур. Группа объектов, детализирующих описание процедур по выбранному перечню описателей (бухгалтерская проводка, система коммуникаций и т. д.).
8. Организационная структура. Традиционная иерархическая структура предприятия с необходимыми характеристиками каждого элемента структуры.
9. Штатная должность. Объект, содержащий описание штатных должностей предприятия. Будучи связанным с оргструктурой, образует штатную расстановку.
10. Сотрудники. Объект с данными о сотрудниках предприятия.
11. Должность. Объект, содержащий описание типовых должностей предприятия.
12. Квалификационные требования. Объект, содержащий описание квалификационных требований предприятия к типовым и штатным должностям.
13. Рабочее место. Объект, группирующий процедуры для описания требуемых рабочих мест (ролей) предприятия; позволяет сформулировать требования к автоматизации процессов.

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