Однако также существуют явные схожие черты между ручными и автоматизированными административными бизнес-процессами. В обоих случаях у административного бизнес-процесса есть цель: распространение информации среди тех, кто в ней нуждается. Для пользователя способ создания этой информации не имеет значения. Другими словами, пользователю все равно, проводится сбор, документирование и обработка данных, на которых базируется информация, компьютерами или людьми; пользователь будет продолжать задавать все те же вопросы. (Конечно, одно различие заключается в том, что автоматизированные методики позволяют удовлетворить требованиям распространения информации благодаря более высокой скорости и более низким затратам на использование компьютеризованных информационных методик, в то время как при ручной обработке данных эти требования могут остаться невыполненными.) Неудивительно, что первые три мероприятия по проектированию административных бизнес-процессов почти не отличаются от аналогичных мероприятий в методе разработки систем. При разработке автоматизированных систем в конце каждой фазы, называемой проектированием логической структуры, определяется так называемая граница между людьми и машинами. Детали того, что происходит внутри границы, определяются далее специалистами по системному анализу и программистами. Они специализируются в оптимальном использовании возможностей компьютера. Детали того, что происходит вне границы, определяются далее специалистами в области ручных административных бизнес-процессов. Они специализируются в области проектирования административных бизнес-процессов в организациях. Очень важной является внутренняя координация мероприятий в обеих областях знаний. Законченная административно-организационная система должна функционировать как единое целое. Часто системные разработчики слишком поздно приглашают экспертов по проектированию прикладных административных бизнес-процессов. В результате экспертам приходится строить процессы вокруг уже установленной компьютерной системы. Не так уж редко это приводит к частичной оптимизации и разочарованию как разработчиков, так и пользователей административных бизнес-процессов. Именно разработчик процесса, а не программист, должен нести ответственность за все мероприятия по улучшению бизнес-процессов. После рационализации процесса следует использовать информационные технологии для дальнейшего улучшения процесса.
6.1 Введение Вся работа команды по улучшению процесса окупает себя в течение Фазы V. Именно в это время все результаты анализа данных и творческого мышления, вложенного в разработку нацеленного на будущее решения, преобразуются в реальное улучшение деятельности. Несмотря па то что столько усилий и внимания было затрачено на проверку полноты нацеленного на будущее решения и правильности проектируемых затрат и сбережений, если решение будет плохо реализовано, то весь процесс может закончиться неудачей. В действительности, именно на этой фазе чаще всего происходят провалы проектов по улучшению бизнес-процессов. Создается впечатление, что энтузиазм и увлечение творческой частью административных мероприятий по улучшению бизнес-процессов (Фазы с I по IV) пропадает во время наиболее приземленной части - мероприятия по внедрению. Очень часто интересы руководства переключаются на новый проект, и из-за этого не соблюдаются правильные приоритеты для приведения процесса к завершению. — 151 —
|