Мы часто слышим, что реорганизация бизнес-процессов (РБП) позволяет предприятиям отказаться от старых методов ведения бизнеса и превратиться в современные, модернизированные компании. Ведущие специалисты по методам управления из Grant Thornton и других консультативных фирм продолжают обсуждать и анализировать примеры успешных проектов РБП на конференциях и семинарах, на телевидении и в деловых журналах.

В последние 20-30 лет компании формировали свои инфраструктуры информационных технологий (аппаратные средства, программное обеспечение, организация сетей) для поддержания производственной деятельности — обработки заявок, подготовки рабочих заданий, производства продукции. Цель РБП состоит в том, чтобы улучшить деятельность предприятия. Например, страховая компания могла бы осуществить РБП для сокращения сроков оформления полисов или для повышения точности согласования исков на компенсации. Авиалиния могла бы реорганизовать порядок оплаты за полеты и посадки пассажиров и отказаться от бумажных билетов, чтобы ускорить для пассажиров весь процесс посадки в самолет. Или производитель мог бы пересмотреть свои закупки, материально-производственное оборудование и способы отгрузки, чтобы уменьшить сроки поставки продукции заказчикам.

По определению, эти инициативы РБП — улучшение, модернизация и ускорение производственной деятельности — подразумевают также перестройку информационных систем. Однако, здесь кроются два вида опасностей:

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

При всем внимании, уделяемом этой новой концепции управления, результаты РБП явно противоречивы. Фактически, 70% типичных попыток РБП не приносит ожидаемых улучшений в намеченный срок. Практика показывает, что соотношение затраты/очевидные результатыпри РБП очень высоко, и столь высокий процент неудач вызывает серьезное беспокойство. Почему успехи так невелики? То ли слишком много планирования (барьер анализ/паралич), то ли слишком мало разработанных сценариев ("Готовься!, Огонь!, Цель")? Возможно, причина в нечеткой направленности процесса изменения или в недостаточном акценте на человеческий фактор, связанный с намеченными переменами. Иногда это происходит еще и из-за недостаточного доверия руководства к процессу.

Как можно повысить шансы РБП на успех? Для РБП в большей степени, чем для любой другой технологии или методологии, ответ заключается в трех словах: связь, связь, связь. Кроме того, успех РБП требует административных гарантий и поддержки руководства. Сторонники проекта должны иметь организационные полномочия для реального проведения изменений. Проекты должны быть признаны и управляться в соответствии с существом предполагаемой РБП. Ожидаемые результаты и связи должны координироваться контекстными диаграммами. Наконец, РБП лучше осуществлять путем сотрудничества между IT- и бизнес-экспертами, чтобы совместными усилиями добиваться управляемых изменений.

Задачи РБП

Цель реорганизации бизнес-процесса – фундаментальное изменение способов деятельности предприятия. Это не должно быть "изменением ради изменений" или оправданием перехода на другие программные продукты. Осуществленная должным образом реорганизации бизнес-процесса – это перспективная "революция через эволюцию", которая начинается с малого и распространяется на всю деятельность компании. В пределах нескольких месяцев должны быть получены реальные результаты, которые существенно — а не в малой степени — тем или иным способом улучшают предприятие, например:

• Ответственность перед заказчиком — Ответственность перед заказчиком – это больше, чем просто обслуживание заказчика, это значит быть к заказчику как можно ближе. Настроение заказчика – это все. Ответственность перед заказчиком означает понимание и удовлетворение его запросов по первому звонку, а не просто ответ по телефону после третьего звонка.
• Ускорение сбыта — Опыт показывает, что в скачках побеждает самый быстрый. В Nabisco, например, скорость доставки товаров считается главным стратегическим фактором успеха в производстве продуктов питания. Избавляясь от бесполезных или избыточных операций, организации могут модернизировать свою деятельность таким образом, чтобы доставлять товары и услуги на рынок быстрее, чем прежде. Это означает новые источники доходов, увеличение прибыли.
• Создание барьеров для конкурентов — компьютерные приложения, которые обеспечивают новые способы укрепления связей с заказчиками, создают эффективные заслоны от конкурентов. Менее вероятно, что удовлетворенный заказчик будет искать другие варианты. Помогая компании стать ближе к заказчикам, РБП может создавать или укреплять барьеры для конкурентов.
• Улучшение качества изделий — Усовершенствование процессов проектирования изделий, их производства и контроля может привести к повышению качества продукции — заметному для заказчиков.
• Введение новшеств — Реорганизация деятельности дает организациям потенциал для введения новшеств другими способами, быстро и непрерывно. В Pfizer Pharmaceuticals, например, изменили технологию и внедрили систему, при которой затраты уменьшились на 33 % при одновременном улучшении качества продукции.

“Сверху вниз” вместо “снизу вверх”

Хотя цели РБП вполне очевидны, существует множество способов их достижения. Одни теоретики РБП, такие, как Майкл Хаммер, говорят: "Не автоматизируйте — избавляйтесь!" К сожалению, простота и категоричность этого предложения оставляют в тени много реальных трудностей, которые препятствуют такому "мгновенному" решению. Стремление начать “с чистой доски” может привести к отказу от полезных технологий. Таким путем можно безвозвратно потерять накопленный ценный опыт. Избавление от каких-то процессов без тщательного анализа может привести к ухудшению вместо улучшения. Другие практики РБП, сторонники эволюционного пути, ратуют за тщательный, строгий анализ систем, целей и задач. В своем желании избежать ухудшения ситуации они так углубляются в анализ, что могут затушевать все усилия РБП. Отсутствие прагматизма и направленности на достижимые цели приводит многих заинтересованных лиц к разочарованию. Временной интервал до достижения положительных эффектов слишком расширяется. На РБП многие смотрят как на бюрократическое мероприятие, бесполезное для производства.

Часто профессионалы-практики IT, изолированные от практиков РБП, просто применяют новые инструментальные средства клиент/сервер, которые быстро моделируют и создают новые системы. Из-за отсутствия всякой стратегии эти приложения были приняты лишь немногими из заинтересованных лиц, или быстро забрасывались и заменялись новыми приложениями в умопомрачительных итерациях. Без понимания бизнес-процессов, для которых эти приложения предполагается использовать, эти попытки обречены на неудачу.

Основная проблема упомянутых подходов – полное отсутствие связи между заинтересованными в РБП кругами. Необходима практическая модель, которая объединит все сферы. Для ее создания нужно определить бизнес-правила и удостовериться, что они поддерживаются приложением.

Специалисты считают, что главное для РБП – уделить первостепенное внимание реализации новых деловых процессов и наметить план изменений в поэтапном, содержательном проекте, управляемом с четким пониманием задач и при полной поддержке руководства. Как только вы сформируете деловые модели "как есть" и "как будет", вы можете оценить ваше приложение и систему управления базой данных, чтобы решить, следует ли компоновать/модифицировать имеющуюся систему или покупать новую. Не пытайтесь делать все сразу. Внесите небольшое изменение в управляемых частях или проектах для быстрого достижения видимых результатов и перейдите к постепенным изменениям во всех других областях.

Осуществление РБП

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

• Формирование понимания — Прежде всего следует определить стратегическую задачу предприятия и связанные с ней критические факторы успеха.
• Осмысление ситуации — Установление и анализ неудачных, не оптимизированных, нерентабельных процессов и операций, которые препятствуют достижению желаемых результатов. Критерием здесь должен быть ответ на вопрос: "Что нужно изменить?"
• Продумывание альтернативного подхода — Как только проблема диагностирована, группы РБП вырабатывают новую стратегию процессов и необходимых измерений, а также оценивают новые варианты бизнеса.
• Перепроектировка бизнес-процесса — Цель состоит в том, чтобы создать модели новых бизнес-процессов, а также текущих операций. Это поможет охарактеризовать новый бизнес-процесс и понять, чем он отличается от имеющегося.
• Выполнение проекта "Как будет" — эта стадия включает не только новые процессы в новой инфраструктуре IT, но и контроль над изменением персонала (то есть обучение, усвоение). Изменения и в том, и в другом плане должны производиться параллельно, по общей схеме.
• Оценка нового потенциала — Регулировка новых процессов и постоянное внедрение в деловые процессы накопленных знаний – ключевая стадия жизненного цикла РБП. Принятие мощного метода IDEF0 для моделей процесса гарантирует, что ваша организация сможет основывать будущие проекты на своем понимании процесса.

Обратите внимание, что эти шаги включают больше технического видения и стратегии, чем технологии. Однако, ключ к успеху РБП лежит не в самих моделях, а скорее в том, как вы используете выбранную модель. Многие практики игнорируют наиболее важный аспект — связь — и рассматривают полный эксплуатационный цикл РБП в виде дискретных, отдельных фаз, независимых от друг друга. Практики РБП, не сторонники связей, стремятся отгородить разные проекты, и даже отдельные стадии. А как только “мероприятие” РБП завершится, организация "сдает назад" – к старым методам и процессам. В этом и кроются основные причины неудач РБП.

Ключевые моменты: переход и связь

В представлении Computer Associates, РБП – это гармоничное, цельное состояние (континуум). Ключ к успеху РБП лежит в преодолении обособленности практиков РБП и профессионалов IT. Главное – сотрудничество.

• Всегда должна быть эффективная связь. Осуществление РБП должно оживить всех заинтересованных в этом процессе — экспертов РБП, персонал предприятия, продавцов, поставщиков и профессионалов IT. Если хоть одна группа будет придерживаться только собственных усилий, в проведении РБП возникнут большие проблемы.
• В задачи РБП входит установление избыточных действий, отказ от нерентабельных операций и улучшение остальных процессов во всех сферах деятельности.
• Связь – это самый решающий фактор при переходе от "этапов" к состоянию (континууму).
• Переход подразумевает также возможность многократного использования РБП в ходе разработки для управления последовательными стадиями РБП.

Без партнерства между экспертами бизнеса и профессионалами IT, без связи среди всех заинтересованных кругов и без возможности напрямую связывать реорганизацию и планирование работы, РБП не достигнет успеха.

Технология РБП

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

• Зафиксировать текущие процессы — инструментальные средства РБП идеальны для графического представления ваших текущих трудовых процессов и помощи в отыскании проблемных и наиболее критичных моментов. Это упрощает сложные идеи и помогает создать общую мысленную модель процесса.
• Определить новые потребности бизнеса — вообразив типичный "рабочий день" вашего персонала или целого отдела, вы можете использовать технологию РБП для поиска лучших способов деятельности организации. Ваши инструментальные средства должны помочь вам сформировать идеи.
• Расчленить и оценить варианты — Поскольку возникнет множество идей и путей их осуществления, вам понадобится метод оценки всех вариантов и выбора самого выгодного из них.

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

Например, как только вы разберетесь с трудовыми процессами, вам захочется:

• Проанализировать ваши схемы РБП с помощью приложений для расчета затрат на производственную деятельность, что поможет оценить ситуацию для реорганизации конкретно вашего бизнеса.
• Исследовать варианты "сделать вместо купить" — задокументировать ситуацию "как будет" и определить наиболее рентабельные способы осуществления этих процессов. Лучший подход может включать ваши существующие приложения или может потребовать покупки готовых решений или заказа их в другой организации. Средства РБП должны помочь вам установить разницу между текущей ситуацией и вашей бизнес-моделью "как будет".
• Направлять в соответствии с моделью РБП разработку ваших приложений, чтобы гарантировать, что новые приложения будут поддерживать новые бизнес-процессы.
• Автоматизировать разработку ваших приложений, используя управляемые со стороны модели средства разработки приложений типа клиент/сервер, для создания новых систем или изменения существующих. Интегрировать с популярными инструментальными средствами и базами данных для ускорения разработки приложений, которые полностью соответствуют новым бизнес-процессам.
• Выделить и проанализировать "низко висящие плоды" — процессы, которые просто необходимо усовершенствовать. Часто это дорогие, проводимые вручную медленные процессы, явно очевидные для заказчика.
• Реализовать вашу модель РБП, используя инструментальные средства моделирования, для выявления скрытых трудностей путем прогонки сценариев "что, если", и оценить результаты.
• Подкрепить проект РБП последовательным обучением персонала.

Computer Associates полагает, что такая интеграция, связь, и сотрудничество в переходный период между стадиями РБП – ключ к успеху РБП. Этот рецепт дает РБП способ реального воплощения, т.к. позволяет вам такую роскошь, как нисходящее (“сверху вниз”) проектирование, одновременно облегчая восходящую (“снизу вверх”) реализацию. Этот подход идет от сбора данных через построение моделей к созданию приложений и постоянно основывается на уже полученных результатах, что ускоряет весь процесс.

Рекомендуемая литература

1. Andrews, Dorine и Stalick. Business Reengineering: The Survival Guide, Englewood Cliffs, New Jersey, Prentice-Hall, 1994.
2. Classe, Alison. "Practice what you preach, tools to help with BPR strategies" Computer Weekly 27 July 1995: 28-29.
3. Clemons, Eric. "Using scenario analysis to manage the strategic risks of reengineering" Sloan Management Review, Summer 1995.
4. Davenport, Thomas. Process Innovation: Reengineering Work through Information Technology, Cambridge, MA, Harvard University Press, 1993.
5. Edgemon, Jim. "Workflow applications help hone I/S competitive edge" Application Development Trends, June 1995: 31-41.
6. Gallagher, Bob. "First looks: LW graphical BPwin: process modeling simplified" Product of the Week. PCWeek, October 25, 1993.
7. Hall, Gene, Jim Rosenthal, и Judy Wade. "How to make reengineering really work" Harvard Business Review, November-December 1993.
8. Hammer, и Champy. Reengineering the Corporation: A Manifesto for Business Revolution, New York, Harper Business, 1993.
9. Hill, Steve and Lee Robinson. A concise guide to the IDEF0 technique, a practical technique for business process reengineering, Puyallup, Washington, Enterprise Technology Concepts, 1995.
10. "Information technology spearheads NATO defense systems, NATO redesigns acquisition and logistics of weapon systems with Logic Works business reengineering tool kit" Government Computing, UK, August 1995.
11. Integration definition for function modeling (IDEF0), Federal Information Processing Standards Publications (FIPS PUBS), National Institute of Standards and Technology, Processing Standards Publication 183, December 21, 1993.
12. Marca, David и Clement McGowan. IDEF0/SADT, business process and enterprise modeling, San Diego, California, Eclectic Solutions, 1993.
13. Martinez, Erwin. "Avoiding large-scale I/T project failure: the importance of fundamentals" Project Management Journal, June 1994.
14. Martinez, Erwin. "Successful reengineering demands IS/business partnerships" Sloan Management Review, Summer 1995.
15. McCarthy, Shawn. "Gunter system fills tall order, Air Force business process re-engineering sets standards for other agencies" Government Computer News July 3, 1995: 45-46.
16. O'Guin, Michael. The Complete Guide to Activity-based Costing, Englewood Cliffs, NJ, Prentice Hall, 1991.
17. Pegden, C. Dennis, Robert Shannon, and Randall Sadowski. Introduction to Simulation Using SIMAN, New York, NY, McGraw-Hill, 1995.
18. Pickell, Stephen. "Process Reengineering Section: BPwin" Data Management Review, September 1995.