Глава 3

Из которой читатель узнает, что такое ERP, кому это нужно и сколько это стоит.

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

Так родились системы класса ERP (Enterprise(-wide) Resource Planning, системы планирования ресурсов предприятия или системы планирования ресурсов в масштабе предприятия), которые представляют собой расширенные MRPII-системы ⁴.

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

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

Если такая система внедрена на предприятии корректно, компания может получить огромную отдачу. Рассмотрим, например, заказ клиента. Типичная ситуация: заказ клиента принят. После этого он начинает долгое, в основном «бумажное» путешествие по предприятию, причем часто он заново вводится в разные программы в разных подразделениях, то в виде заказа, то в виде (части) производственного плана и т. п. Очень часто такое путешествие оканчивается задержкой выполнения заказа, или его потерей. Тем временем никто (или почти никто) на предприятии не знает, в каком состоянии заказ и где, по производственной цепочке, находится. Это происходит потому, что финансовый отдел, например, не может увидеть информацию складской, производственной программы (если таковая есть, что для наших предприятий редкость) или программы сбыта, и не может определить, изготовлен ли заказ, отгружен ли, и не пора ли выставлять счет на оплату. «Вы должны позвонить на склад» - рефрен, который очень часто слышат заказчики.

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

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

Это и есть ERP или, по крайней мере, мечта о ERP.

Однако реальность гораздо жестче.

Вернемся к «бумажному» путешествию заказа на минуту. Процесс может быть и не столь эффективен, однако он прост. Финансовый отдел делает свою работу, отдел продаж делает свою работу, склад отгрузки делает свою работу. Если что-то идет не так за стенами нашего отдела - это не наши проблемы. Но не с ERP-системой. С ERP менеджер отдела продаж уже не просто оператор, вводящий в компьютер чье-то имя, заказанное количество, и нажимающий клавишу Enter. Теперь заказ перекликается с сальдо клиента (допустимый кредит), наличием товаров на складе сегодня или на дату заказа. Заплатит ли клиент вовремя (постепенно предприятия отказываются от практики предоплаты)? Сможем ли мы вовремя отгрузить? Эти решения никогда ранее менеджер не должен был принимать, хотя они затрагивают и клиента и компанию в целом. Но «проснуться» должен не только менеджер по продажам. Начальник склада/кладовщик, который раньше держал информацию о запасах в голове или в «амбарной» книге (на карточке учета) теперь должен вводить эту информацию в режиме реального времени. Если этого он делать не будет, в сбыте увидят, что необходимого для заказа количества на складе нет. Никогда раньше не предъявлялись столь высокие требования к ответственности за информацию и оперативности взаимодействия между отделами.

Как долго длится проект внедрения ERP-системы?

Предприятия, имеющие внедренные ERP-системы, потратили на это немало усилий. Не стоит доверять рекламным прокламациям, когда фирмы-поставщики ERP решений говорят о среднем времени внедрения в 4-6 месяцев. Такие короткие (да, именно так, шесть месяцев - очень короткий проект) проекты всегда имели те или иные ограничения: предприятие было маленьким или внедрялись только отдельные модули системы, например финансы, склады и т. п. В последнем случае компания получила не более чем очень дорогое учетное или бухгалтерское решение ⁵. Для того, чтобы внедрить ERP «честно», придется изменить методы бизнеса, а также методы работы персонала предприятия. Это, кстати, довольно часто становится самой главной проблемой при внедрении, но об этом чуть дальше.

Понятно, что стоимость внедрения системы также крайне велика. Сами посудите, во сколько может обойтись проект по внедрению рассчитанный на 1,5-2 года (это вполне реальный срок для ERP-решений), если стоимость одного рабочего места составляет в зависимости от пакета от 1500 долларов - и это только то, что корпорация платит разработчику! А ведь внедрение ERP-систем настолько сложная и трудоемкая задача, что разработчики, как правило, этим не занимаются, отдав этот рынок специализированным компаниям, которые (опять же, в идеале) знают, что требуется их потенциальному заказчику и каким именно образом лучше подогнать под него имеющиеся шаблонные решения и, что не менее, а наверное даже и более важно, как изменить бизнес-процессы, которые работают в компании заказчика, с тем, чтобы они как можно лучше соответствовали модели, от которой плясали разработчики. В итоге счет подчас идет на сотни миллионов долларов - а это очень серьезные цифры даже для американских компаний, не говоря уже о российских.

Глава 4

Из которой читатель узнает, почему систему ERP, как правило, нельзя сделать силами собственного отдела АСУ и чем плохи покупные системы ERP.

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

Самостоятельная разработка, как правило, занимает слишком много времени. Создание полноценной ERP-системы - проект не одного года. Предприятие, решив внедрить ERP-систему, безусловно, рассчитывает окупить вложенные средства. В этом случае, каждый месяц неиспользования системы ведет к потере дополнительной прибыли, которая могла бы быть реализована с использованием системы.

Будет ли она работать? В данном вопросе преимущество готового решения в том, что его работоспособность можно проверить (или, что более реалистично - в его работоспособность можно поверить) до вкладывания средств в покупку. Для самостоятельной разработки это не так: после нескольких лет, потраченных на разработку, может оказаться, что система не работает. Конечно, неработоспособность системы может быть обусловлена неправильным использованием. Но в девяти случаях из десяти проблемы при эксплуатации системы будут «свалены» на программу.

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

Теперь посмотрим на стандартную систему. Она может быть неполной. Неполнота системы может быть выражена в отсутствии необходимой функциональности, или в том, что ее функциональность не подходит существующим методам ведения бизнеса. Даже если бы существовали системы, подходящие на 100%, рано или поздно потребовалось бы внесение в них каких-либо модификаций - это неизбежность.

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

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

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

Могут быть трудности в совместном использовании с другими системами. Структура системы (бизнес логика, СУБД и язык программирования, с использованием которых разработана система) может не позволить создать эффективное сопряжение ее с другими системами, использующимися или предполагаемыми к использованию на предприятии.

Могут существовать ошибки (баги). «…чрезвычайно высока вероятность того, что завтра утром солнце встанет на востоке. Вы просто можете быть уверены в этом. Примерно такая же вероятность того, что практически в любой ERP-системе будут баги» ⁷. К сожалению, это так, и для предприятия, использующего ERP-систему для решения своих бизнес-проблем, основная трудность состоит в том, что ошибки эти могут быть исправлены только поставщиком системы. Медленное исправление ошибок может обусловить срыв сроков проекта внедрения, или даже остановку работы предприятия. Чтобы избежать этого - тщательно выбирайте систему и обращайте внимание на процедуры исправления ошибок, предлагаемые поставщиками.

В заключении отметим, что, несмотря на все минусы готовых систем, мировая практика внедрения ERP-систем подтверждает нецелесообразность самостоятельной разработки. Например, из компаний США, использующих, внедряющих или выбирающих ERP-систему, только 1,5 % выбрали путь создания системы собственными силами (см. таблицу):

[i41924]