http://www.cnews.ru/newcom/index.shtml?2005/03/30/176507

30.03.05

Описание бизнес-процессов: как избежать ошибок

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

Определиться с целями

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

Хотя этап описания БП почти всегда присутствует в плане работ по проекту, его результаты оцениваются крайне неоднозначно. Основной причиной этого является ряд ошибок, которые зачастую делают как заказчики, так и исполнители. Уже при принятии решения об инициации описания БП обычно и совершается наиболее распространенная ошибка – недостаточно четко формулируются цели подобного исследования, что ведет к дальнейшему непониманию между заказчиком и исполнителем.

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

Эти ожидания редко формулируются в какие-либо конкретные требования, обычно ИТ-консультантам приходится иметь дело с более-менее абстрактными пожеланиями, такими как: «отдел Х работает неэффективно, надеюсь, ваша система наведет там порядок», «хочется, чтобы мы работали как передовые компании в отрасли, например, как фирма Y». Причем даже такие пожелания зачастую теряются либо изменяются до неузнаваемости, пока доходят до рядовых исполнителей. Чтобы избежать последующих ошибок, эксперты рекомендуют составлять задание на описание БП не менее серьезно и подробно, чем ТЗ на программный комплекс.

«Как есть» и «как должно быть»

В зависимости от целей, которые ставит перед внедрением ИС руководство предприятия, при описании бизнес-процессов «как есть» (as is) необходимо уточнять требуемый «разрез» и детализацию. Причем подобные требования могут различаться для разных департаментов. Например, если в новой системе планируется организовать работу отдела снабжения таким образом, чтобы минимизировать вероятность сговора между менеджерами отдела и поставщиками, то при описании процессов «как есть» целесообразно уделить особое внимание существующим принципам выбора поставщиков.

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

Подобных «рекомендаций» при описании БП стоит опасаться

Многие ИТ-консультанты включают в план работ по проекту пункт «Описание бизнес-процессов «как должно быть» (to be)». На практике полноценную работу по этому пункту могут выполнить не так много компаний, действующих на российском рынке. Как правило, это наиболее крупные фирмы, имеющие опыт построения БП как западных компаний, так и передовых отечественных, и умеющие разумно применять данный опыт к конкретному российскому предприятию с учетом отраслевой и прочей специфики.

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

Справедливости ради стоит сказать, что описание процессов «как должно быть» действительно является сложной задачей. Если заказчик не предъявляет четких требования по данному блоку, ИТ-консультанту трудно понять, чего в действительности от него хотят и в каком направлении следует двигаться. Задать такой вектор, безусловно, необходимо самому заказчику, поскольку лучше него конкретный бизнес никто не знает.