Поделиться
Описание бизнес-процессов: как избежать ошибок
Первым этапом построения информационной системы на предприятии обычно является описание его бизнес-процессов. Однако специфика российского рынка такова, что из-за ошибок, совершенных на этой стадии, выполненные работы зачастую оказываются бесполезными.Определиться с целями
Внедрение информационных систем (ИС) среднего и крупного класса сопровождается, как правило, описанием бизнес-процессов (БП) предприятий-заказчиков. Чаще всего подобная документация составляется на этапе предварительного обследования, позволяющего определить, насколько успешно БП организации можно перенести в рамки предлагаемой ИС. Такую цель обычно подразумевают ИТ-консультанты, однако руководство организаций, внедряющих ИС, неизменно видит вопрос несколько шире.
Хотя этап описания БП почти всегда присутствует в плане работ по проекту, его результаты оцениваются крайне неоднозначно. Основной причиной этого является ряд ошибок, которые зачастую делают как заказчики, так и исполнители. Уже при принятии решения об инициации описания БП обычно и совершается наиболее распространенная ошибка – недостаточно четко формулируются цели подобного исследования, что ведет к дальнейшему непониманию между заказчиком и исполнителем.
Внедрение дорогостоящих систем среднего и крупного класса для предприятия не является самоцелью. Заказчик зачастую считает, что использование таких систем, помимо чисто технических аспектов, послужит отправной точкой для определенной перестройки части работ на предприятии.
Эти ожидания редко формулируются в какие-либо конкретные требования, обычно ИТ-консультантам приходится иметь дело с более-менее абстрактными пожеланиями, такими как: «отдел Х работает неэффективно, надеюсь, ваша система наведет там порядок», «хочется, чтобы мы работали как передовые компании в отрасли, например, как фирма Y». Причем даже такие пожелания зачастую теряются либо изменяются до неузнаваемости, пока доходят до рядовых исполнителей. Чтобы избежать последующих ошибок, эксперты рекомендуют составлять задание на описание БП не менее серьезно и подробно, чем ТЗ на программный комплекс.
«Как есть» и «как должно быть»
В зависимости от целей, которые ставит перед внедрением ИС руководство предприятия, при описании бизнес-процессов «как есть» (as is) необходимо уточнять требуемый «разрез» и детализацию. Причем подобные требования могут различаться для разных департаментов. Например, если в новой системе планируется организовать работу отдела снабжения таким образом, чтобы минимизировать вероятность сговора между менеджерами отдела и поставщиками, то при описании процессов «как есть» целесообразно уделить особое внимание существующим принципам выбора поставщиков.
Если для отдельного департамента планируется ввести систему ключевых показателей результативности, то имеет смысл «заказать» при описании БП учет количественных показателей работы. При отсутствии же подобных требований наверняка получится описание БП структурных подразделений, сделанное по единой схеме. Поэтому, если заказчик рассчитывает на получение результата в определенных, интересующих его разрезах, ему следует заранее сформулировать их.
 Подобных «рекомендаций» при описании БП стоит опасаться |
Многие ИТ-консультанты включают в план работ по проекту пункт «Описание бизнес-процессов «как должно быть» (to be)». На практике полноценную работу по этому пункту могут выполнить не так много компаний, действующих на российском рынке. Как правило, это наиболее крупные фирмы, имеющие опыт построения БП как западных компаний, так и передовых отечественных, и умеющие разумно применять данный опыт к конкретному российскому предприятию с учетом отраслевой и прочей специфики.
Наряду с успешными примерами, в России налицо совершенно явная тенденция – многие ИТ-консультанты не слишком четко представляют, как подступиться к описанию БП «как должно быть». Для них, если описание «как есть» показало, что процессы в целом ложатся в структуру предлагаемой ИС, этот этап работ считается законченным, и они стремятся как можно быстрее начать внедрение. В результате заказчик рискует в качестве результата описания процессов «как должно быть» получить набор диаграмм существующих БП с «ценными рекомендациями» перенести их в предлагаемую ИС.
Справедливости ради стоит сказать, что описание процессов «как должно быть» действительно является сложной задачей. Если заказчик не предъявляет четких требования по данному блоку, ИТ-консультанту трудно понять, чего в действительности от него хотят и в каком направлении следует двигаться. Задать такой вектор, безусловно, необходимо самому заказчику, поскольку лучше него конкретный бизнес никто не знает.
Даже в случае четко сформулированного задания на описание бизнес-процессов успешной работе на этом этапе мешает другая распространенная ошибка – проведение подобного исследования только силами консультантов, без привлечения внутренних специалистов. БП на любом действующем предприятии, как и работа по их оптимизации, очень динамичны. По этой причине рассчитывать на то, что модели и диаграммы, полученные в результате описания БП, будут действительны еще в течение долгого времени – безусловно, неверно. На практике описание бизнес-процессов, полученное по результатам обследования, после внедрения ИС зачастую превращается в статичный документ, который через определенное время просто устаревает и перестает представлять какую-либо ценность.
Избежать данной ситуации можно в том случае, если в штате предприятия присутствует человек, знакомый с методологией описания БП. Оптимально, если такой сотрудник принимает участие в описании бизнес-процессов совместно с консультантами. В таком случае после завершения работ по внедрению ИС можно будет успешно использовать ценную информацию, полученную по результатам обследования, – при планировании расширения функциональности ИС, внедрении систем менеджмента качества, для использования различными консультантами и т.д.
Эксперты отмечают, что российской спецификой является выделение для описания БП не самых квалифицированных сотрудников ИТ-фирмы. Зачастую ИТ-консультанты считают, что описание БП – задача технически не слишком сложная, поэтому ее можно поручить сотрудникам без большого опыта работы. В итоге вместо опытных специалистов, имеющих стаж работы на схожих предприятиях, заказчик во время обследования имеет дело с новичками. Последствия подобных заблуждений нетрудно предугадать – если для ИТ–консультантов обследование действительно приносит пользу, поскольку они фактически обучаются за счет заказчика, то для заказчика полученный в результате пакет документов не содержит абсолютно никаких ценных рекомендаций.
Между тем, если ИТ-компания позиционирует себя не только как «фирму, автоматизирующую то, что есть», то подобный подход, безусловно, недопустим. Рисовать диаграммы технически действительно несложно, однако только опытные сотрудники могут с ходу определить наиболее значимые «узкие места» БП.
Защитить свои интересы заказчик может сравнительно несложным образом – согласуя состав команды, проводящей описание БП. В этом случае ИТ-консультант должен будет предоставить список своих представителей с указанием наличия у них сертификатов и опыта работы. Такая практика еще не получила широкого распространения на российском рынке, однако, по мнению аналитиков, в дальнейшем она станет стандартной процедурой.
Выбор направления
Еще одна ошибка, которую порой делают предприятия, устанавливающие ИС, – априорная ориентация на описание БП «сверху вниз», начиная с основных, стратегических процессов организации. ИТ-консультанты любят пугать клиентов рассказами про «заплаточное построение ИС», статистикой о якобы баснословно дорогом способе внедрения «снизу вверх», в рамках которого приходится постоянно перенастраивать налаженные системы.
Между тем, в подобной агитации есть известная доля лукавства. Построение ИС «сверху вниз» теоретически во многих случаях действительно предпочтительнее, однако число неудачных проектов при таком подходе ничуть не ниже. Современная российская практика показывает, что на многих предприятиях излишне широкие проекты порой так и не начинаются, поскольку затраты только на обследование организации начинают превышать все мыслимые пределы.
Нередко встречается ситуация, когда глобальное построение на предприятии современной западной системы в итоге превращается во внедрение одного-двух модулей. Стоит помнить, что, когда ИТ-консультант агитирует за глобальное внедрение и, соответственно, описание БП «сверху вниз», за его словами может скрываться элементарное желание заполучить проект на максимально возможную сумму.
Эксперты отмечают, что большинство проблем при описании БП связаны с тем, что заказчики плохо представляют себе, для чего именно нужно проводить этот этап построения ИС, что они хотят получить в качестве результата и каким образом работать с ним дальше. Между тем, описание БП присутствует почти во всех проектах по внедрению ИС, словно дань некоторой моде. Компании же, внедряющие ИС, при отсутствии сформулированных требований заказчика просто проводят его по пути наименьшего сопротивления – наименее затратным для себя способом.
Андрей Матаренко / CNews
Короткая ссылка
