В теме 9.1.4 были рассмотрены экономические преимущества моде­ли MRP II/ERP как бизнес-модели. Поток доходов от проекта внедрения ERP-системы оценивался исключительно с точки зрения различий меж­ду бизнес-моделью MRP II и традиционными подходами к планированию и управлению производством. Подобный подход представляется вполне справедливым для проекта внедрения ERP-системы. Однако реинжи­ниринг бизнес-процессов дает возможность в некотором смысле «пере­внедрить» ERP-систему, обеспечив тем самым дальнейшее приращение эффективности основного бизнеса.

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

· объединение нескольких работ в одну;

· принятие решений самими работниками;

· сокращение объема проверок и контроля за счет совокупного или от­сроченного контроля;

· сокращение необходимости согласований;

· сочетание преимуществ децентрализованных и централизованных операций.

Приведем небольшой поясняющий пример из области оптовой тор­говли нефтепродуктами. Эта торговля обычно подразумевает составле­ние следующих документов:

· рамочного договора между поставщиком и покупателем, определяю­щего условия взаиморасчетов;

· приложения к договору, регламентирующего номенклатуру, объемы поставки и цены нефтепродуктов на ближайший месяц или квартал;

· заявки покупателя на отгрузку нефтепродуктов, включающей в себя объем и номенклатуру отгружаемых нефтепродуктов, место назначе­ния и ряд других параметров.

Контроль выполнения бизнес-правил (в упрощенном представлении) включает в себя проверки:

· наличия договора и приложения сданным контрагентом; О соответствия объема и номенклатуры поставки по заявке остатку (остаткам) позиций по приложению на текущий период;

· соответствия заявки текущему лимиту отгрузки НПЗ^[41] с учетом уже поступивших заявок и их приоритетности;

· непревышения покупателем установленного ему лимита кредитования;

· включения цены транспортировки в цену нефтепродуктов, что будет учтено при выставлении счета покупателю, и т.д.

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

Рассмотрим теперь практическую реализацию такого контроля. Вы­полнение вышеперечисленных операций требует знаний о товарных остатках на заводе, сальдо расчетов с клиентом по всем договорам (ко­торых, вообще говоря, может быть несколько), производственном пла­не завода на ближайшее время вплоть до планового выполнения заявки, содержании договоров и приложений к ним. Далее, заявка на отгрузку — естественная основа для формирования производственного плана НПЗ. Из сказанного вытекают требования к системе, реализующей эти воз­можности:

· наличие справочника контрагентов и постоянное его ведение, исклю­чающее пропуск и дублирование данных контрагентов;

· наличие справочника реализуемых нефтепродуктов с аналогичными требованиями к его ведению;

· возможность разработки плана производства с соответствующими требованиями к справочникам и алгоритмам.

Вышеперечисленные возможности, необходимые для автоматиза­ции контроля бизнес-правил, полностью присутствуют в ERP-системе и составляют примерно 60—80% объема функциональных требований к последней (см. подтему 9.1.4). Таким образом, ERP-система — едва ли не оптимальный инструмент для выполнения подобных операций. Вмес­те с тем система должна работать в существенно ином режиме:

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

· работоспособность ERP-системы становится непременным условием сбытовых операций. В результате стоимость времени даже небольшо­го простоя и требования к службе сопровождения многократно воз­растают;

· специфика работы менеджера требует доступа к системе не только из стационарного офиса, но и из офиса клиента, что предполагает уда­ленный доступ в ERP-систему с мобильного компьютера;

· все торговые документы вводятся в систему непосредственно менед­жерами. Ошибка при вводе исходных данных потребует повторного подписания торгового документа у контрагента;

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

На основании вышеприведенных требований следует выделить два проекта развития ИТ. Бизнес-проект состоит в реализации в ERP-системе нового сервиса — контроля соблюдения бизнес-правил. Инфраструк­турный проект заключается в повышении устойчивости ERP-системы и организации удаленного доступа в нее с мобильных компьютеров. Это, в свою очередь, требует решения проблем надежности, пропускной спо­собности, безопасности и т.д.

По мере внедрения и тестирования новых бизнес-процессов для них разрабатывается ФСА/ФСУ-модель. Она позволяет оценить доходность нового сервиса в терминах КПР и ФСА, а также стоимость единицы вре­мени простоя сервиса для различных категорий простоев. После переда­чи новых сервисов в эксплуатацию на них с временных объектов затрат списывается стоимость обоих ИТ-проектов. На основании этих данных производятся оценка результатов проекта реинжиниринга и пересмотр СУС. Последний необходим для учета новых сервисов и вероятного из­менения параметров существующих сервисов. Описанная последова­тельность действий приведена на рис. 9.14.

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

Впрочем, затраты на ИТ-проекты вполне могут быть оценены в соответствии с расширенной моделью ФСА.

Экономические параметры сервисов ИТ в новой модели бизнес-про­цессов определяются на этапе тестирования последней. К этому моменту также становятся известными точные данные по затратам на связанные проекты развития ИТ. На основании тех и других данных производится экономическая оценка связанных проектов ИТ. Она позволяет опреде­лить параметры новых и измененных сервисов, необходимых для пере­смотра СУС, а также проконтролировать результаты проекта реинжини­ринга в целом.

Рис. 9.14 Принятие решений по связанным ИТ-проектам в составе проекта реинжиниринга.