СТАТЬЯ
08.05.01

Практический способ реорганизации бизнес-процессов

От теории “сверху вниз” к реализации “снизу вверх”

Три основных фактора в реорганизации бизнес-процессов (РБП): связь, связь, связь

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

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

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

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

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

Задачи РБП

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

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

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

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

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

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

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

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

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

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

В представлении Computer Associates, РБП – это гармоничное, цельное состояние (континуум). Ключ к успеху РБП лежит в преодолении обособленности практиков РБП и профессионалов 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.

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Обсудить на форуме Computer Associates
Отправить ссылку на страницу по e-mail

Interface Ltd.
Тel/Fax: +7(095) 105-0049 (многоканальный)
Отправить E-Mail
http://www.interface.ru
Ваши замечания и предложения отправляйте автору
По техническим вопросам обращайтесь к вебмастеру
Документ опубликован: 08.05.01