Архивы: по дате | по разделам | по авторам

Системы класс ERP для чайников

Архив

автор : Владимир Гуриев 05.11.2001

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

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

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

Речь у нас пойдет о том, что не всегда понятно, почему некоторые программные комплексы стоят миллионы долларов. Еще более непонятно, почему некоторые компании согласны платить миллионы долларов за это программное обеспечение. И последнее, самое темное место: что получают покупатели, заплатив такие деньги.

Речь пойдет о системах класса ERP ¹, «магических» программных комплексах управления предприятием. Несмотря на некоторый скепсис, который читатель, возможно, обнаружит в статьях, - авторы вовсе не считают, что король «голый». Более того, Сергей Питеркин, например, зарабатывает себе на жизнь именно внедрением подобных решений. Просто не всем стоит одеваться в бутике - даже если есть деньги.

Глава 1

Из которой читатель узнает подробности о печи Франклина, и о том, что такое точка заказа и оптимальный объема заказа.

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

Началось все в середине XVIII века, когда Бенджамин Франклин (тот самый парень, изображенный на стодолларовой купюре) изобрел знаменитую «франклиновскую» печь. Рекламная листовка по совместительству выполняла роль инструкции по изготовлению печи, в ней описывались материалы, из которых собирается печь и порядок сборки. Эта листовка считается первым документом, раскрывающим процесс производства конечного продукта и присутствие необходимых комплектующих (bill of materials). Как ни странно, до Франклина подобным образом никто ничего не распространял - по крайней мере, до нашего времени более ранние документы такого рода не дошли ².

Тем не менее, Франклин со своим замечательным отопительным прибором - скорее исключение, чем правило. О контроле за производством продукции начали задумываться только с начала XIX века. Первая полная система контроля была внедрена на заводе в Уотертауне в 1880 году. Первоначально промышленников интересовало, прежде всего, наиболее эффективное управление собственными линиями, а точнее - чтобы на складе всегда были материалы, необходимые для производства товаров; иными словами, чтобы линии не простаивали. Чтобы достичь оптимального уровня загруженности линии, естественно, требуется решить задачу планирования производства. По большому счету, этого промышленникам удалось добиться только в начале XX века (по самому большому счету - в случае непрогнозируемого спроса не удалось добиться до сих пор). И - пошло, поехало.

В 1915 году Харрис изобретает EOQ (economic order quantity) - одну из первых моделей оптимального определения объема заказа (производственного или на закупку), которая позволяет сократить издержки на возобновление и хранение запасов материалов, полуфабрикатов или готовой продукции. В 1934 году Уилсон вводит (придумывает или, если хотите, открывает) понятие точки (пере)заказа - ROP (reorder point). В течение довольно долгого времени главным для промышленников при оптимизации производства является умелое сочетание моделей EOQ и ROP. В простейших случаях оба эти понятия весьма наглядны. Если предположить, что мы производим товар, который пользуется постоянным спросом, а поставщики нас никогда не подводят, то с расчетом показателей EOQ и ROP справится даже ребенок. Так, экономичный объем заказа рассчитывается по формуле

где D - объем годового производства нашего товара, S - стоимость заказа, а H - стоимость хранения единицы продукции в течение года. Точка перезаказа в этом случае рассчитывается не намного сложнее.

Понятие ROP позволяет определить момент времени, когда запасы предприятия становятся меньше допустимого уровня и требуется инициировать их возобновление. Понятно, что в реальной жизни и EOQ, и ROP рассчитывать на порядок сложнее, в основном из-за того, что условия, в которых реализовано производство, мягко говоря, не идеальны: и спрос далеко не постоянен, и одно и то же сырье используется для изготовления разных товаров и вообще - неизвестных, которые могут повлиять на расчет этих величин, довольно много. Тем не менее, к началу сороковых было создано довольно много разработок, позволяющих оптимизировать производство и запланировать требуемый объем выдаваемой на-гора продукции. И только благодаря использованию связки EOQ и ROP удалось добиться снижения загруженности складских помещений на 15%, что, разумеется, привело к снижению производственных затрат (в некоторых случаях - до 20%).

План продаж товаров определенным образом коррелирует с планом пополнения ресурсов, требуемых для производства товаров. Собственно, попытка подобным образом упорядочить систему управления ресурсами предприятия выглядит наиболее естественной ³. Однако более никаких особых чудес от подобных технологий планирования ждать не приходилось.

Глава 2

Из которой читатель узнает, что такое APICS, почему и кем были придуманы стандарты MRP и что такое системы класса MRPII.

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

В итоге усилиями Джозефа Орлики и Оливера Вейта (Joseph Orlicky, Oliver Wight) был разработан метод расчета необходимых для производства материалов, получивший название MRP (material requirement planning, управление материальными ресурсами). Во многом благодаря целенаправленной работе Американской ассоциации по управлению запасами и производством (APICS) метод MRP приобрел значение неофициального стандарта. В первой версии MRP не было ничего революционного - в ней просто были собраны и интегрированы все имеющиеся в наличии экономические модели того времени, пригодные для планирования производства.

Главной сущностью, которой оперирует MRP-система, является объект материального учета (item). Обычно это сырье и материалы, сборочные единицы, полуфабрикаты, то есть практически все, что угодно, если из этого всего, что угодно можно собрать некий конечный продукт.

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

Второй, «кит» на котором базируются MRP-системы, - ведомость материалов или спецификация (bills of materials). Это - вспомним «франклиновскую» печь - список материалов и описание технологии сборки конечного продукта. Третий «кит» - MPS, то есть принцип объемно-календарного планирования (по поводу связи между MPS и объемно-календарным планированием российского розлива смотри сноску выше).

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

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

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

Как ни странно, аббревиатура MRPII расшифровывается иначе, чем MRP. Если в первом случае, под MRP понимается планирование поставок комплектующих (Material Requirements Planning), то во втором случае речь идет уже о планировании всех значимых ресурсов предприятия (Manufacturing Resource Planning). «Двоечку» же добавили потому, что аббревиатуры случайным образом совпали. Таким образом, хотя преемственность между MRP и MRPII видна невооруженным глазом, это безусловно очень сильно отличающиеся в концептуальном плане друг от друга системы. Если система класса MRP предназначена в основном для эффективного управления имеющимися ресурсами, то в системы класса MRPII уже встроен работоспособный аналитический аппарат, с помощью которого можно с довольно приемлемой степенью точностью делать прогнозы.

Классическая система MRPII, в зависимости от конкретной реализации разработчиком софта и направленности на определенный тип предприятий может включать в себя следующие модули:

Master Production Scheduling (Составление основного плана производства).
Material Requirement Planning (Планирование необходимых материалов).
Bill of Materials (Спецификации и технологические маршруты изделий ).
Inventory Control (Управление запасами).
Shop Flow Control (Диспетчирование/Управление производством).
Capacity Requirement Planning (Планирование производственных мощностей).
Input/output control (Управление цехами по уровню НЗП [незавершенное производство]).
Distribution Resourse Planning (Управление запасами многих предприятий/баз или дистрибьюторских центров). Планирование запасных ресурсов распределения).
Purchasing (Материально техническое снабжение).
Costing (управление издержками)
Financial Planning (Управление финансами).

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

Например, гипотетическая MRPII-система может, в добавление к вышеперечисленным, содержать следующие модули:

Tooling Planning and Control (Планирование и контроль производственных операций).
Sales and Operation Planning (Планирование продаж и производства).
Simulation (Моделирование).
Performance Measurement (Оценка результатов деятельности).
Demand Management (Управление спросом).

Значительное отличие систем MRPII от систем класса MRP состоит в том, что модули - несмотря на очевидное разделение - тесно между собой интегрированы. И эта интеграция обладает некоторым синергетическим эффектом - в идеале результаты работы каждого модуля анализируются системой в целом, что позволяет учесть произошедшие изменения сразу в контексте всей системы. Это с одной стороны повышает эффективность работы системы, а с другой повышает ее устойчивость к изменениям внешних условий.

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

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

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

1 (обратно к тексту) - ERP - Enterprise Resource Planning (планирование ресурсов предприятия). Класс учетно-транзакционных компьютерных систем управления предприятием в основном западных производителей, предназначенных для планирования и управления всеми ресурсами предприятия, необходимыми для производства, реализации и учета продукции. Подробнее см. APICS Dictionary, 9^th edition.
2 (обратно к тексту) - Речь здесь идет, скорее, о западной цивилизации - наверняка среди тех же египетских или шумерских табличек найдется достаточное количество подобных документов. Другое дело, что ни египтяне, ни потомки шумеров не являются сегодня главными поставщика систем класса ERP.
3 (обратно к тексту) - Здесь речь идет об объемно-календарном планировании (MPS, master planning scheduling). Надо отметить, что объемно-календарное планирование, традиционно используемое в России - это не классический MPS. Корни многих проблем наших предприятий лежат в том, что они не используют MPS (просто не знают, что это такое) с тем смыслом, который он несет в MRPII-системе.

Глава 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 % выбрали путь создания системы собственными силами (см. таблицу):

	Процент
Система ERP (без каких-либо дополнений)	39,8
Лучшие элементы нескольких ERP систем	3,9
Система ERP совместно с другими системами (специализированные разработки - PDM, CAD/CAM, MES и т. п.)	50,0
Несколько ERP систем совместно с другими системами (специализированные разработки (PDM, CAD/CAM, MES и т.п.))	4,9
Полностью собственная разработка	0,5
Собственная разработка совместно со специализированными системами	1

[i41924]

4 (обратно к тексту) - По большому счету, ERP - это всего лишь новое маркетинговое имя для MRPII-системы, придуманное агентством Gardner Group, и поддержанное и раскрученное большинством поставщиков ERP. Основное отличие, которое все-таки пытаются притянуть за уши в этом историческом споре - новая программно-аппаратная платформа. То же самое происходит сейчас и с раскруткой все тем же Gardner класса систем ERP-II.
5 (обратно к тексту) - Об этом подробнее см. в «Чайники для систем класса ERP».
6 (обратно к тексту) - Наличие дополнительной функциональности, однако, не всегда хорошо, так как она усложняет систему. Об этом - см. ниже.
7 (обратно к тексту) - Tom Wallace, MRP-II: Making It Happen.

Корпоративные информационные системы это довольно большой рынок, на котором присутствует довольно много производителей программного обеспечения. Впрочем, как это обычно случается, значительная часть этого рынка «окучена» несколькими крупными игроками, в то время как всем остальным приходится работать либо с компаниями, которые не могут себе позволить большие, дорогие решения, либо в определенных рыночных нишах, если универсальные монстры не могут обеспечить должной функциональности.

Самой первой, самой известной, самой популярной (более 13 тысяч клиентов по всему миру), а также самой раскрученной в прессе компанией, является, безусловно, компания SAP со своей системой R/3.

Это немецкая корпорация, которая была организована в начале 1970-х годов, всю жизнь работала на ниве автоматизации деятельности корпораций и в начале 1990-х выпустила свою систему R/3. R/3 является самой большой и сложной ERP-системой - в ней реализовано более тысячи бизнес-процессов. Впрочем, конкуренты R/3 говорят, что эта система слишком сложна для большинства предприятий и пользоваться ею во многих случаях все равно что забивать гвозди кувалдой. Однако на популярности R/3 такие заявления сказываются не сильно - главным сдерживающим фактором является, вероятно, все-таки цена.

На российском рынке R/3 также присутствует довольно давно и «болезни локализации» по большому счету ею уже пройдены. На долю R/3 выпали первые крупные неудачные внедрения, когда оказалось, что рассчитанные на довольно консервативное (и неповоротливое) западное законодательство системы не могут нормально функционировать в правовом хаосе, когда принятые законы могут быть введены в действие задним числом. Именно несовместимостью R/3 с причудами российского законодательства и методами ведения российского бизнеса вызван крах первой попытки внедрения ERP в Газпроме. С тех пор, правда, утекло довольно много воды и сегодняшним ERP-системам намного легче, чем первопроходцам - и в законодательстве кутерьмы поменьше и многие подводные камни уже известны. Кроме того, за последние несколько лет внедренцы, похоже, вбили в голову потенциальным и реальным клиентам нехитрую заповедь, что фискальный учет, главной задачей которого есть необходимость отчитаться перед государством, не является проблемой, которую обязаны решать системы класса ERP. Довольно часто используется связка из ERP-системы и гораздо более примитивной по существу, но зато более вариативной системы, на которой и формируются необходимые для отчетности перед государственными органами документы.

На втором месте по популярности стоит система Oracle Applications от корпорации Oracle. Это одно из очень популярных решений не в последнюю очередь благодаря популярности собственно СУБД Oracle. Кроме того, некоторые модули Oracle Applications способны взаимодействовать с приложениями SAP R/3. Всего в мире установлено около 7000 систем, построенных на базе Oracle Applications.

Baan очень известная система «со сложной судьбой». Несмотря на то, что в начале 90-х гг. прошлого века программные комплексы от Baan были очень популярны, уже к концу тысячелетия финансовые трудности, испытываемые компанией, сказались как на ее имидже, так и на популярности ее продуктов. Тем не менее BaanIV, которой Baan обязана своей славой, относительно благополучно сменилась на BaanErp.

Не очень известные у нас системы, которые нельзя не упомянуть, - OneWorld от J. D. Edwards и PeopleSoft от одноименной компании. Первая система создана американской компанией J. D. Edwards (интересно, что в названии этой компании так или иначе отражены имена всех трех ее основателей - Jack Thompson, Dan Gregory и Ed McVaney). Локализованная версия системы появилась в России совсем недавно (у всех перечисленных выше систем также есть локализованные для России модули). А вот следующая система - PeopleSoft от компании PeopleSoft - пока не локализована. Это относительный новичок на рынке КИС - компании «всего» 14 лет. Тем не менее система весьма популярна и особенно часто используется, если ключевым вопросом является упорядочение работы с кадрами. Вообще говоря, существует некоторое условное разделение, вызванное спецификой систем. Так, считается, что SAP R/3 очень хорошо подходит для энергетических предприятий, Baan наиболее близок к производству, а PeopleSoft, например, для «работы с кадрами». На самом деле, все вышеперечисленные системы более-менее универсальны и если заточенность Peoplesoft под энергетику еще можно поставить под сомнение, то уж с кадрами прекрасно умеют работать все ERP-системы.

Что касается российского рынка, то у нас в стране на рынке активно присутствуют трое из большой пятерки (Baan, R3, Oracle) и множество систем от производителей поскромнее (Scala, e by Epicor, Axapta и др.). Кроме того, не следует забывать и об отечественных производителях, которые также довольно активно работают над созданием корпоративных информационных систем, хотя в общем случае причислять российские корпоративные программные продукты к системам класса ERP было бы слишком смело. По крайней мере, самые известные производители - «Галактика», «Парус», «АйТи» - избегают употребления терминов ERP/MRP по отношению к собственным продуктам, предпочитая более нейтральную и не привязанную к толкованиям APICS аббревиатуру - КИС. Впрочем, существует достаточное количество российских ERP-систем, которые этого термина не стесняются, но они пока не на слуху.

В нижней ценовой категории находится платформа «1С» (и аналогичные ей «конструкторы»), на базе которой также можно построить MRP-решения. Об уместности сравнения систем на базе «1С» и той же «Галактики» можно, конечно, спорить, но то, что теоретически на базе инструментария от «1С» возможно построить систему, которая формально отвечала бы стандартам MRP и даже может быть MRPII - довольно очевидно. Для компаний, которые не готовы платить за автоматизацию более 10-20 тысяч долларов, это вполне может оказаться приемлемым решением.