Тезисы лекций и электронные ресурсы

1
ТЕЗИСЫ ЛЕКЦИЙ ДЛЯ ВЫПОЛНЕНИЯ КОНТРОЛЬНОЙ РАБОТЫ №1
ПО ДИСЦИПЛИНЕ «ERP-СИСТЕМЫ»
ДЛЯ МАГИСТРОВ НАПРАВЛЕНИЯ ПОДГОТОВКИ 240700 «ИС И ТЕХНОЛОГИИ»
ПЛАН
Тезисы лекции №1. Реинжиниринг бизнес-процессов…………………………………….1с.
Тезисы лекции №2 ERP-система и примеры бизнес-приложений ERP-систем……….12с.
Тезисы лекции №3 Мировой рынок ERP-систем……………………………………………………16с.
Тезисы лекции №4 Критерии выбора ERP-систем для России…………………………23с.
Тезисы лекции №5. Характеристики MRP систем…………………………………………26с.
Тезисы лекции №1. Реинжиниринг бизнес-процессов.
1.
Понятие реинжиниринга. Как научно-практическое направление, реинжиниринг бизнеспроцессов впервые появился в США и за несколько лет превратился в одну из ведущих и активно
развивающихся отраслей информатики. Сегодня начинается продвижение консалтинговых услуг и
инструментариев по реинжинирингу и на российский рынок. Отечественная практика применения
реинжиниринга показала, что этот метод необходим, особенно в условиях проведения глобальной
экономической реформы и активного внедрения России в мировую экономическую систему.
Впервые термин "реинжиниринг бизнес-процессов" (от англ. business process reengineering, BPR) был введен
М.Хаммером, который определяет этот вид деятельности как "фундаментальное перепроектирование бизнеспроцессов компаний для достижения коренных улучшений в основных актуальным показателях их
деятельности: стоимость, качество, услуги и темпы".
В западном мире (и, в первую очередь, в США) реинжиниринг приобретает все большую и большую
популярность. Чтобы проиллюстрировать эту тенденцию, приведем несколько цифр.
Компании США затратили на проекты по реинжинирингу бизнес-процессов в 1994 году около 37 млрд.
долларов. В течение ближайших лет рост затрат на решение этих задач ожидается на уровне 19% в год.
По данным компании Emst & Young, 100 крупнейших банков Северной Америки затратили в 1999 году около
3,9 млрд. долларов только на реинжиниринг своих подразделений. За последние полтора года правительство
США инициировало более 250 проектов по реинжинирингу, а сегодняшний рынок инструментальных средств
поддержки BPR оценивается более чем в 100 млн. долларов и растет со скоростью около 60% в год.
По результатам опроса, проведенного Emst & Young среди финансовых директоров 80-ти крупнейших
компаний США, основной мотивацией проведения реинжиниринга было улучшение сервиса и качества
продукции (услуг), а также снижение расходов.
М.Хаммер рассматривает BPR как революцию в бизнесе, которая знаменует отход от базовых принципов
построения предприятий и превращает конструирование бизнеса в инженерную деятельность. Возможность
такой революции обусловлена, в первую очередь, новейшими достижениями в области информационных
технологий, специалисты которой начинают играть ведущую роль в конструировании бизнеса.
BPR является направлением, возникшим на стыке двух различных сфер деятельности - управления
(менеджмента) и информатизации. Именно поэтому реинжиниринг требует новых специфических
средств представления и обработки проблемной информации, понятных как менеджерам, так и
разработчикам информационных систем. Подобные средства требуют интеграции ключевых
достижений информационных технологий и создания соответствующих инструментальных средств
поддержки реинжиниринга.
Одной из основных особенностей BPR является ориентация реинжиниринга не на функции, а на процессы.
Причем из всех концепций менеджмента, основанных на процессах, BPR рассматривается как наиболее
эффективная, революционность которой обусловлена современным состоянием информационных технологий.
Таким образом, реинжиниринг бизнес-процессов ориентирован на коренную перестройку всей деятельности
предприятия, а не на частичные изменения в той или иной сфере управления.
Поскольку BPR оперирует с такими понятиями, как бизнес-процесс, бизнес-система, деловая
процедура, то в целях более четкого восприятия этих терминов следует дать следующие определения.
Бизнес-система - это связанное множество бизнес-процессов, конечной целью которой является выпуск
продукции. Под продукцией, понимают товары, услуги и документы.
Бизнес-процесс - это горизонтальная иерархия внутренних и зависимых между собой функциональных
действий, конечной целью которых является выпуск продукции или отдельных ее компонентов.
Деловая процедура - это функция, задача, цепь событий, происходящих в течение определенного промежутка
времени и обладающих познаваемым результатом.
Основными показателями оценки эффективности бизнес-процессов являются:
2

количество производимой продукции заданного качества, оплаченное за определенный интервал
времени;
 количество потребителей продукции;
 количество типовых операций, которые необходимо выполнить при производстве продукции за
определенный интервал времени;
 стоимость издержек производства продукции;
 длительность выполнения типовых операций;
 капиталовложения в производство продукции.
Перечислим базовые принципы, положенные в основу реинжиниринга бизнес-процессов:
 несколько рабочих процедур объединяются в одну, т.е. происходит горизонтальное сжатие процесса (по
имеющимся оценкам, горизонтальное сжатие ускоряет выполнение процесса примерно в 10 раз);
 исполнители принимают самостоятельные решения, т.е. осуществляется не только горизонтальное, но и
вертикальное сжатие процессов (наделение сотрудников большими полномочиями и увеличение роли
каждого из них приводит к значительному повышению их отдачи);
 шаги процесса выполняются в естественном порядке;
 процессы имеют различные варианты исполнения ( тот или иной вариант выбирается в зависимости от
конкретной ситуации, состояния и т.д.);
 работа выполняется в том месте (подразделении, отделе), где это целесообразно (устраняется
излишняя интеграция, что приводит к повышению эффективности процесса в целом);
 уменьшается количество проверок и управляющих воздействий;
 минимизируется количество согласований путем сокращения внешних точек контакта;
 единая точка контакта обеспечивается уполномеченным менеджером (в тех случаях, когда шаги
процесса либо сложны, либо распределены таким образом, что их не удается объединить силами
небольшой команды).
Подводя итог теме реинжиниринга, заметим, что BPR - это не просто модная тенденция, а следствие
жесточайшей конкурентной борьбы, которая требует внедрения наукоемких инновационных
технологий как средств повышения производительности и эффективности деятельности предприятия.
Рассуждая о бизнес-процессах, мы до сих пор не формулировали, что же это собственно такое, и делали это
сознательно - формулировки, как правило, вызывают множество споров, зачастую, совершенно не нужных.
Говоря о том, почему необходимо обратить внимание на бизнес-процессы, мы, тем самым, уже отразили их
суть. Теперь добавим формулировку, которая, как нам кажется, наиболее точно определяет это понятие.
Процесс - последовательность исполнения функций (работ, операций), направленных на создание результата,
имеющего ценность для потребителя. Данная формулировка позволяет отметить важнейшие составляющие
процесса:
 "последовательность исполнения функций" - обращает наше внимание на то, что важно выстраивать
порядок, регламент их исполнения. Посмотрите, как выстраивается порядок выполнения процессов на
Вашем предприятии - системно или стихийно?
 "направленных на создание результата" - этим подчеркивается предназначение процесса Не может
быть процесса без результата, а если таковой процесс существует, становится непонятно, зачем?
Взгляните на свои процессы - всегда ли они ведут к тем результатам, которые нужны фирме?
 "результата, имеющего ценность для потребителя" - формирует ориентированность на клиента как у
сотрудников, так и у фирмы в целом. Это означает, что ценность сделанной работы, оказанной услуги
оценивает не исполнитель, а потребитель, клиент процесса. Причем неважно - внешний (покупатель),
или внутренний (соседний отдел, цех). Посмотрите, волнует ли сотрудников какого-либо отдельного
подразделения, как его работу оценивают те, для кого они эту работу делали. Если нет, точно так же
ни одного из них не будет волновать, довольны ли клиенты фирмы.
Иными словами, управляя процессами, мы организуем эффективное взаимодействие как внутри фирмы, так и
вовне - с окружающим миром. Соответственно, это позволяет снизить транзакционные издержки (издержки
некачественного взаимодействия) - внутренние (сотрудники и подразделения между собой) и внешние
(фирмы с покупателями, поставщиками, инвесторами и т.д.).
Не существует конечного или стандартного списка процессов. Их столько, сколько необходимо для
осуществления определенного вида деятельности. Выделяют две основные группы процессов - основные и
вспомогательные. В результате основных процессов создается добавленная стоимость (новое качество); они
кросс-функциональны (то есть в их рамках происходит взаимодействие как с клиентами, так и с
поставщиками). Вспомогательные процессы - процессы управления (планирование, оргструктура, учет,
анализ), создания инфраструктуры управления и бизнеса (информационного обеспечения, системы качества,
производственных систем) и процессы разработки новых продуктов и услуг.
3
Существующая тенденция в развитии процессов - "вытягивание" их за пределы фирмы, то есть создание
кросс-организационных процессов, в том числе организация процесса электронной коммерции (e-бизнес).
Создание и оптимизация кросс-организационных процессов направлены на снижение внешних
трансакционных издержек предприятия.
Для управления процессами как системой необходимо сформировать процессную структуру, то есть
выстроить их в определенном, взаимосвязанном порядке. Так как каждый процесс предназначен для
получения какого-либо результата, который используется далее для получения следующего результата на
дальнейших этапах и более высоких уровнях, данная структура должна обеспечить, в конечном счете,
достижение общих целей компании. Структура процессов, таким образом, определяется структурой дерева
целей предприятия. А для этого должны быть сформулированы цели, правда, это уже вопросы стратегии. Что,
впрочем, лишний раз наглядно показывает, взаимосвязь всех структур на предприятии, и невозможность
наладить эффективную работу в отдельных сферах деятельности, не наведя порядок на системном уровне, то
есть, не выстроив систему управления. Именно тогда совершенствование процессов становится наиболее
эффективным способом достижения целей.
Реинжиниринга - бизнес-процессы, их совершенствование является огромным резервом повышения
эффективности деятельности предприятия. А для этого необходимо осмыслить природу бизнес-процессов,
понять, какое значение они имеют для предприятия, как следует их правильно изменять. Само внимание к
бизнес-процессам, их совершенствованию требовало от менеджеров нестандартного подхода. Постепенно
реинжиниринг, который предлагает сломать существующую на предприятии систему и построить ее заново на
основе такого революционного изменения бизнес-процессов, стал превращаться в систему управления,
"обрастать" технологией, становиться на почву научного обоснования. Стали появляться соответствующие
программные продукты. От реинжиниринга, как метода реорганизации бизнеса через коренную перестройку
имеющихся бизнес-процессов, управленческая мысль перешла к понятию "бизнес-инжиниринг", то есть
система создания бизнеса, как инженерной науки, через проектирование и управление бизнес-процессами. В
бизнес-инжиниринге во главу угла ставится процессный подход, где объектом управления являются процессы
на предприятии. И в этом смысле можно считать, что реинжиниринг, как техника их преобразования, стал
лишь составной частью бизнес-инжиниринга. Выбор этого средства требует отказа от традиционного взгляда
на управление, его серьезного переосмысления, и именно поэтому до сих пор не только у нас, но и на Западе,
бизнес-инжиниринг еще не стал инструментом массового применения.
Таким образом, использование бизнес-инжиниринга начинается с того, что руководители, которые хотят взять
его на вооружение, должны перестроить свое сознание. А менять устоявшиеся убеждения - ой, как сложно!
Это могут сделать менеджеры инновационного типа, которые постоянно находятся в поисках нового и
осмыслении этого нового для совершенствования управления своим предприятием.
Итак, в чем же суть процессного подхода в управлении? До сих пор, фактически, господствовал
функциональный подход. То есть, считалось, что фирма - это некий механизм, который обладает набором
функций. Эти функции распределяются среди подразделений, где их исполняют сотрудники предприятия в
зависимости от своей специализации. В соответствии с принципом разделения труда, провозглашенного в
свое время Адамом Смитом, исполнение функций по мере усложнения производства дробилось на все
большее количество операций. Выполняя свои узкоспециальные задачи, сотрудники перестают видеть
конечные результаты труда всего предприятия и осознавать свое место в общей цепочке. Такая система
заставляет персонал хорошо исполнять функции, но не ориентирует на достижение результата. А ведь именно
результативность - мера успеха бизнеса. К тому же, в большинстве случаев действия на предприятии не
ограничиваются рамками одного подразделения. Службы взаимодействуют, передают работу друг другу по
этапам. И зачастую на взаимодействие между подразделениями уходит больше времени, чем на выполнение
собственно работы, так как представители одного подразделения никак не заинтересованы в эффективном
сотрудничестве с представителями соседнего. Это порождает различного рода разногласия, в которых
забываются общие интересы. Зато горячо отстаиваются интересы собственные. Конфликт интересов - еще
одна большая проблема, порождаемая природой функциональной организации труда.
Пример. Реинжиниринг: бизнес-процессы или зоны ответственности? В.А. Гончарук,
marketconsult@mtu-net.ru
http://consult.webzone.ru
Лет 8 назад консалтинг был относительно прост. Почти на любом предприятии изменение 2-х - 3-х главных
функций в управлении давало чуть ли не стопроцентный прирост эффективности. Несколько лет после
кризиса требовали уже более скрупулезной работы. Чтобы получить аналогичные результаты, стало
необходимым отладить множество процедур, большинство из которых выполнялось, в принципе, правильно,
но могло быть оптимизировано. Последние же годы вновь начинают напоминать докризисную эпоху. Хотя
80% проектов связано преимущественно с быстрым ростом компаний, оставшаяся часть направлена на
ликвидацию последствий неудачного реинжиниринга бизнес-процессов, и требует кардинальных мер.
4
Оставляя в стороне вопрос возможной некомпетентности или неподготовленности людей, проводящих
реинжиниринг, попробуем разобраться в самом предмете.
На рисунке показано деление предприятия по функциональным отделам, каждый из которых возглавляет
руководитель (А, Б, и т.д.). Пунктиром отмечены процессы, которые имеют простую конфигурацию (процесс
1), смыкаются (процессы 2 и 3), разветвляются (процесс 4). В их реализации необязательно задействованы все
отделы фирмы или в одной и той же последовательности.
Идеи, поставленные во главу угла сторонниками данного подхода, примерно следующие:
1. Реинжиниринг бизнес-процессов позволяет организовать фирму или бизнес кардинально по-новому и
наиболее оптимальным образом («революционное преобразование» по Хаммеру).
2. Предприятие интересует не статичный, а динамичный результат, и бизнес-процесс, имеющий на выходе
товар или услугу, позволяет его получать.
3. «В наш век высоких технологий» бизнес-процесс превосходно поддается автоматизации, и в новом качестве
может быть максимально эффективен.
Под всеми тремя идеями можно подписываться не глядя. Но …
1. Революционные преобразования планируются и при оптимизации оргструктуры предприятия, разработке
стратегий, концепции развития. Для этого необходимо желание и готовность заказчика, а реинжиниринг
бизнес-процессов – всего лишь один из возможных методов.
2. Никто и никогда не реформирует предприятие для достижения вчерашних показателей. Грамотный
руководитель или консультант, применяя любые методики, старается строить динамически устойчивую
фирму. И результат получает не абстрактный процесс, а люди, выполняющие определенные задачи.
3. Бизнес-процессы необходимо автоматизировать, именно в их логике удобно ставить задачи программистам,
но стоит ли удобство программирования объявлять первым приоритетом для предприятия?
В «сухом остатке» идей реинжиниринга бизнес-процессов имеется одна относительно прогрессивная идея,
впрочем, актуальная еще с 70-х годов, – это автоматизация предприятия. И одна важная идея отсутствует –
причина, по которой бизнес-процессы могли бы работать. Их можно красиво нарисовать и даже жестко
внедрить почти в задуманном виде, но ведь нас, кажется, интересовал динамичный результат?
Динамику создают люди, принимая решения в изменившейся ситуации – внедряя и корректируя процессы по
мере необходимости. Без людей любая управленческая схема нежизнеспособна. И методисты реинжиниринга
предлагают решение данной проблемы: вводом «хозяина» бизнес-процесса, управляющего его течением.
Причины, по которым такой подход принимает заказчик, объяснимы. На обычном быстрорастущем
предприятии ряд функций выполняется со сбоями, потоки информации местами прерываются, важные
решения опаздывают. Отладить весь механизм часто представляется более сложным, чем «заткнуть дыру»,
назначив «хозяина» бизнес процесса, ответственного за стыковки между отделами.
Почему это не работает, тоже понятно. Руководители отделов, освобожденные от ответственности за
результат, благополучно занимаются «футболом», посылая «хозяина» процесса вместо себя договариваться со
смежниками. А «хозяин», не имея возможности заставить работать не подчиняющихся ему руководителей,
либо спускает все на тормозах, либо привлекает для решения вопроса директора предприятия. (Последний и
оказывается в матричной структуре единственным реально ответственным).
В проектных организациях, консалтинговых и рекламных фирмах матричная структура может быть
эффективна. Эффективность достигается сохранением принципа единоначалия. Если всю власть (в т.ч. право
распоряжаться бюджетом) по проекту отдать «хозяину», если все функциональные отделы в рамках
установленных процедур и в заранее оговоренные сроки будут обязаны выполнять его заказы, то цели
проекта будут достигнуты. Бизнес-процесс эффективно реализуется.
Заметим, что в перечисленных отраслях проект является действительно автономным (т.е. его можно адекватно
определить), и он малопредсказуем (т.е. неизвестно, какие ресурсы понадобятся для очередного проекта).
5
Отсюда проектно-матричная структура как меньшее зло по сравнению с постоянной реорганизацией
предприятия.
В более предсказуемом бизнесе, связанном с производством и распределением товаров, а не услуг,
эффективное управление бизнес-процессами также давно и успешно реализуется. «Хозяин» бизнес-процесса
называется начальником дивизиона, а структура, в которой все это реализуется, дивизиональной. В этом
случае «хозяин» также обладает всеми необходимыми полномочиями, единолично отвечает за результат и
осуществляет взаимодействие с общими службами предприятия по заранее определенным процедурам с
позиции заказчика. Под начальником дивизиона группируются все процессы, ориентированные на
определенный рынок.
Проблемы с внедрением процессного управления начинаются там, где понятия удобства автоматизации
начинают смешивать с понятиями управления. Ведь мало кому приходит в голову управлять по статьям
бухгалтерского баланса. Отчего же в товарной группе, ориентированной на единый рынок, вдруг назначать
нескольких ответственных за товары, проводящих самостоятельную политику? Замена вертикального
управления на горизонтальное в большинстве случаев невозможна, а их совмещение неоправданно.
Достаточно проблем с определением количества и задач функциональных подразделений, чтобы добавлять к
ним аналогичные с группировкой бизнес-процессов, которые еще и сконфигурированы гораздо сложнее (см.
рис.)
Строго говоря, в функциональной структуре тоже можно провести реинжиниринг любой детализации и даже
назначить «хозяев процессов» наряду с имеющимися начальниками отделов. Чтобы заставить работать такого
монстра, необходимо сохранить принцип единоначалия и четко расписать зоны ответственности, полномочия
и процедуры взаимодействия для каждого руководителя отдела, хозяина процесса и каждого стыка
матрицы. Тогда эффективность структуры упадет не так низко, как это происходит на большинстве фирм.
Так что же, отказаться от идеи усиления горизонтальных связей, оптимизации и последующей автоматизации
бизнес-процессов? Нет, конечно. Просто несколько по-другому расставить приоритеты, не принося в жертву
моде работоспособность предприятия.
В общем виде алгоритм реинжиниринга предприятия может быть следующим:
·Вначале оцениваются сильные и слабые стороны предприятия – его потенциал (который составляют, в
первую очередь, идеи и люди, опыт и квалификация). По наиболее интересным для фирмы направлениям
оцениваются потенциальные и реальные рынки.
· Затем для перспективных рынков выстраиваются альтернативы позиционирования (возможность стать
розничной сетью, крупным оптовиком, производителем, законодателем мод, и т.д.). Выбираются наиболее
приемлемые альтернативы и согласовываются между собой.
· Затем формулируются общие стратегические цели предприятия (которые могут охватывать разные рынки и
отрасли) и цели бизнесов.
· Затем для каждого бизнеса разрабатываются средне- и краткосрочные стратегии, позволяющие достичь
поставленных целей (например, программа создания импортозамещающего продукта для захвата нового
сегмента рынка, или программа развертывания региональных представительств с постепенным вытеснением
независимых дилеров).
· Когда стратегии определены, прорабатываются мероприятия по их реализации, оптимальным образом
выстраивается оргструктура (включая все технологии взаимодействия подразделений, бизнес-процессы, а
также системы планирования, стимулирования и контроля).
· Затем по каждому бизнесу формируются бюджеты, сводятся в общий, проводится коррекция
запланированных мероприятий, и выстраивается годовой оперативный план. Реализация плана тщательно
контролируется.
Бизнес-процессы корректируются (или выстраиваются совершенно по-новому) на стадии разработки
структуры, когда становится ясным ее стратегическое предназначение. Степень «революционности»
преобразований определяется принятыми стратегиями. А работоспособность бизнес-процессов
обеспечивается, как это ни парадоксально, отсутствием у них «хозяев».
Такое «крамольное» заявление необходимо поддержать аргументацией, поэтому рассмотрим сначала случай,
когда «хозяин» у бизнес-процесса есть. И, допустим, фирма настолько проникнута «правильным»
корпоративным духом, что, несмотря на многоначалие, вовремя и качественно делает свое дело. Тогда работа
типичного менеджера по продукту выглядит примерно так:
Он организует исследования рынка и определяет, каким образом должен развиваться продукт.
Он формулирует задание дизайнерам на разработку внешнего вида продукта, конструкторам – на его
потребительские качества, технологам – на состав, экологичность, себестоимость продукта.
Он определяет для производства объем и график выпуска продукта.
6
Вместе с рекламистами и маркетологами разрабатывает программу продвижения продукта (не забыв
согласовать ее с коллегами по другим продуктам ассортимента).
Он разрабатывает сбытовикам план по сбыту, и логистикам – план поставки продукта в точки реализации.
Он…
Абсурд? У него не хватит квалификации, чтобы делать всю работу за всех? Тогда что же он может делать?
Похоже, только следить за своевременным и качественным выполнением обязанностей функциональными
подразделениями предприятия. Причем и здесь он вынужден полагаться на заключения специалистов, и если
технолог утверждает, что сковородки можно делать исключительно из титана, с ним приходится соглашаться.
(Начальник дивизиона в этой ситуации поискал бы другого технолога).
Бизнес процессы современного предприятия слишком сложны, чтобы один «хозяин» мог охватить их
полностью. А поскольку его задача сводится к координации действий функциональных подразделений, то
почти всегда ее эффективнее решать другим способом, без участия «хозяина»
Что теоретически достигается вводом данной фигуры?
Заинтересованность в результате бизнес-процесса у конкретного человека, облеченного определенными
полномочиями.
Контроль, осуществляемый заинтересованным лицом.
Инициация разработки или изменения бизнес-процесса, переставшего решать полезные задачи.
На практике, предприятию более выгодна совокупная результативность бизнес-процессов, которые тесно
связаны между собой. (И если бы мы плодили «горизонтальных хозяев», кто-то должен был озаботиться
налаживанием связей между ними). Задача общей результативности отчасти решается определением целей
компании и доведением их до каждого менеджера. Отчасти – вводом системы стимулирования, поощряющей
достижение общефирменных целей (в заработной плате всех сотрудников имеется весомая составляющая,
привязанная к результатам фирмы в целом). Отчасти – правильным распределением зон ответственности
функциональных подразделений: в эти зоны обязательно должны входить процедуры взаимодействия со
смежниками.
Тогда на стыках отделов проявляются не полностью совпадающие интересы смежных структур, в увязке
которых эти структуры весьма заинтересованы. Результатом увязки становится работоспособный компромисс
– процедуры взаимодействия, устраивающие обе стороны до тех пор, пока способствуют достижению общего
результата, и пока четко соблюдаются. Нарушение сроков или качества в передаче продукта (товара,
информации, услуги) от подразделения к подразделению сдвигает баланс интересов, поэтому сразу
становится предметом разбирательства, инициируемого «ущемленным» отделом. То есть, как сам бизнеспроцесс реализуется разными функциональными подразделениями, так и контроль за его качественным
выполнением является распределенной функцией, осуществляемой подразделениями по зонам
ответственности.
Остается решить важный вопрос разработки новых и коррекции старых бизнес-процессов. И он успешно
решается заменой «хозяина» процесса на заказчика. Любой бизнес-процесс нужен для чего-то, входящего в
компетенцию одного из функциональных подразделений, поэтому любое подразделение получает право и
обязанность инициировать необходимые предприятию процессы в рамках своей зоны ответственности.
Например, ввод новой товарной группы в сбытовую сеть может предложить отдел маркетинга, проведя
плановое исследование целевого сегмента. Или это может сделать отдел закупки, получив от поставщика
информацию о свойствах нового модельного ряда. Или директора магазинов, ориентируясь на текущий спрос,
предложат расширить ассортимент. В зависимости от источника получения заказа будут реализованы
различные бизнес-процессы (в двух случаях они начнутся с обучения сбытовиков новому товару, в одном – с
оценки рентабельности закупки).
Подразделение-заказчик принимает результаты бизнес-процесса и отвечает за их эффективное использование.
Структуры-исполнители отрабатывают свои части согласно установленным процедурам.
Распределение зон ответственности в первую очередь, и реинжиниринг бизнес-процессов во вторую,
позволяет, кроме прочего, получить оптимизационный эффект без кардинальной ломки успешных
технологий, не вписывающихся в матричную схему. Элементы матрицы могут существовать в проектных
подразделениях предприятия, но для структуры в целом гораздо перспективнее иметь четкое выполнение
обязанностей функциональными единицами, чем стрелочника на каждом стыке.
Что же касается автоматизации и перевода компании на «рельсы прогресса», то для этой цели как раз и
желателен хозяин процесса, чьей главной задачей будет перевод запросов руководителей функциональных
подразделений на язык постановки задач программирования. Только реинжиниринг предприятия должен быть
выполнен до того.
2. Как добиться успеха в безнадежных проектах
7
Константин Берлинский, berlicon@yahoo.com системный аналитик Департамента информационных
технологий при Правительстве Республики Молдова (Кишинев)
Впервые опубликовано в журнале "Открытые системы" №10 2002
Многим руководителям ИТ-проектов знакомы ситуации, когда прекрасно спланированный процесс не
укладывается во временные рамки. Несмотря на то что сроки были определены с запасом, одни модули
"забирают" все доступные ресурсы, другие сразу после появления на свет удаляются за ненадобностью, а
постоянные изменения требований окончательно разрушают проект.
Все это признаки типичного безнадежного проекта [1]. Интерес к способам решения проблем, возникающих в
процессе разработки проектов, не ослабевает. Основной методологией разработки в нашей организации
является Rational Unified Process (RUP), поэтому представленные в статье решения ориентированы на
продукты компании Rational Software. Однако тех же результатов можно достичь, используя аналогичные
инструменты.
Основные черты безнадежных проектов изложены в [2]; там же рассказывается, что делает их таковыми и как
их распознать еще до принятия стратегических решений. Напомним факторы, которые переводят проекты в
разряд безнадежных:
 административные проблемы: хаотичный процесс разработки; много политики; устаревшие
практики и стандарты; чрезмерный оптимизм; "непрозрачность" работ для заказчика; постоянно
изменяющиеся требования; затрудненные коммуникации; слабая мотивация сотрудников;
 проблемы проектирования: концептуальная неполнота и противоречивость; отсутствие единой
терминологии; недостаточная инкапсулированность модулей;
 проблемы разработки: повторное изобретение колеса; игнорирование требования удобства
использования; проблемы с документацией; плохо налаженное тестирование.
Информационную систему крайне трудно разрабатывать без четкой методологии. В своих проектах мы
используем адаптированную под наши нужды технику RUP. При этом артефакт Business Vision становится
Концепцией Системы, документом на 5-10 страниц, описывающим основные архитектурные моменты
информационной системы. Business Use Case Model в нашем понимании становится Техническим Заданием
(ТЗ), документом, который согласовывается с заказчиком и описывает информационную систему с его точки
зрения. Составные части ТЗ: бизнес-процесс, организационная структура предприятия, состав документов,
технология проекта, различные поясняющие диаграммы (схема движения информации, основные потоки
работ и т.п.). Далее, мы выделяем Технический Проект (Analysis Model), в котором описывается вид на
систему с точки зрения программистов: структура выходных форм; список запросов и таблицы базы данных;
внешние интерфейсы; доступные модулям процедуры сервера приложений и перечень функций каждого
модуля.
На рис. 1 отображено распределение ролей в проекте. Системный аналитик пишет ТЗ и согласовывает его с
заказчиком, проектировщик делает ТП и ставит задачи программистам. Реализованная информационная
система тестируется отделом контроля качества совместно с программистами и представителями заказчика; в
случае успеха отдел тиражирования занимается внедрением программного обеспечения.
8
Рис. 1. Методология разработки проектов
Большие проблемы в разработке проекта создает обилие политики и принятие решений, затрагивающих чьито должностные обязанности; поэтому очень важно иметь в составе команды человека из высшего звена,
который решал бы "политические" вопросы еще на уровне концепции.
Не менее острой проблемой является наличие в организации устаревших практик и стандартов. Если
коммерческим компаниям с этим, как правило, удается справиться, то в государственных учреждениях
стандарты оформления документов, документооборот и разработка значительно бюрократизированы.
Действенным решением служит коренная модернизация отделов стандартов качества и технической
документации, внедрение новых стандартов и технологий (ISO, CMM, RUP и т.д.), а также написание
собственных методик.
При планировании графика работ мешают давление заказчика с целью сокращения сроков и чрезмерный
оптимизм участников команды. С первым справиться можно, либо отстояв реальные сроки, либо повысив
требования к профессионализму и численности проектной команды путем увеличения бюджета. "Оптимизму"
разработчиков что-то противопоставить трудно. Каждый программист учитывает время на собственно
разработку модуля, не принимая во внимание коммуникации с другими членами команды и вопросы
интеграции подсистем. Решение, как обычно в таких случаях, "лежит" на поверхности: необходимо
привлекать к обсуждению плана проекта не только руководство, но и непосредственных разработчиков.
Главной причиной недовольства заказчика обычно является непрозрачность процесса разработки. Заказчик
выдвигает требования к информационной системе, объясняет бизнес-правила, а системный аналитик, общаясь
с ним, разрабатывает ТЗ. Однако "на выходе" система часто не вполне соответствует исходным запросам,
особенно в случае изменения условий бизнеса. Поэтому важно сделать заказчика частью команды. В этом
смысле очень привлекательна методология экстремального программирования, одним из постулатов которой
является присутствие заказчика "в одной комнате с программистами". Заказчик объясняет user story
(ключевые функции информационной системы), и ее реализуют за строго определенное время.
К сожалению, "идеальных" заказчиков мало и проблемы прозрачности и изменяющихся требований
приходится решать иными методами. Для наглядности информации в ТЗ мы применяем графические
стереотипы основных терминов и понятий системы; до написания кода приложений согласуем формы
интерфейса, а текущая бизнес-модель, автоматически сформированная модулем WebPublisher из Rational
Suite, всегда доступна для просмотра в формате HTML. В случае изменения бизнес-требований заказчик
сообщает об этом системному аналитику, и тот исправляет модель информационной системы. Проектировщик
определяет масштабы изменения и отражает их в ТП, а затем передает новую постановку задач
программистам (рис. 2).
Проблемы изменения требований оказывают еще более негативное влияние на проект в случаях, когда
затруднены коммуникации - как между заказчиком и командой, так и внутри нее. Наш заказчик "распылен"
(деятельность нашей организации связана с автоматизацией госструктур и построением единых регистров
населения, транспорта, правовых единиц и т.п.), поэтому основными средствами взаимодействия становятся
совещания и рабочая документация проекта. Чтобы совещание было успешным, следует учесть ряд моментов.
Тему совещания надо четко определить, подготовив список конкретных вопросов; приглашаются только
нужные люди с полномочиями принятия решений; оптимальное число участников - 4-7 человек; по каждой
проблеме нужно достичь хотя бы временного, "промежуточного" решения.
Разработку легче, эффективнее и самое главное дешевле вести, используя дорогих профессионалов:
системных аналитиков, архитекторов, проектировщиков, кодировщиков и тестировщиков. Однако эти
рекомендации применимы только для тех организаций, которые вышли на достаточно высокий уровень
финансовой и информационной зрелости. В наших условиях больше подходит вариант, когда к одному "гуру"
прикрепляется от одного до трех "учеников". Большинство сотрудников заинтересовано в профессиональном
росте и, как следствие, в повышении самооценки и возможности успешной карьеры. Не менее важно
обеспечить получение удовлетворения от сделанной работы и налаживание атмосферы сотрудничества в
команде.
Как известно, среди проблем проектирования ключевое место занимает проблема отсутствия концептуальной
целостности и непротиворечивости архитектуры. Поэтому важно назначить архитектора продукта,
ответственного за все его стороны. Кроме того, необходимо отделить архитектуру (т.е. определение продукта
в восприятии пользователя) от его разработки [1]. Однако ничто так не вредит переходу от проектирования к
программированию, как оторванность ТЗ от реального кода. Системного аналитика и проектировщика нужно
подключить к программированию. Это позволит добиться осведомленности системного аналитика (а,
следовательно, и заказчика) и проектировщика о реальном положении дел, лучшей согласованности между
архитектурой и реализацией, более действенной коммуникации. Именно так можно построить эффективную
команду, а не просто группу разработчиков.
9
Рис. 2. Технология цикла разработки
В этих аргументах есть некоторые расхождения с "постулатами" RUP, но на практике безусловное разделение
функций между архитекторами и исполнителями, чьи творческие таланты и идеи подавляются, приводит к
плачевному результату. Архитекторы "витают в облаках", разрабатывая маловразумительные спецификации, а
кодировщики вынуждены заполнять информационные пробелы собственным пониманием проблемы, о чем
аналитик и заказчик узнают последними. Дело вовсе не в том, чтобы дать кодировщикам широкие
возможности по реализации своих творческих замыслов, напротив, "собственное мнение" кодировщику
противопоказано - программирование сегодня не искусство, а ремесло. Однако довести до архитекторов
проблемы непосредственно кодирования необходимо; менеджер проекта должен представлять себе, как
диаграммы, прекрасно выглядевшие на бумаге, реализуются в коде. Поэтому наиболее эффективно
привлечение многофункциональных специалистов, имеющих знания в нескольких смежных областях.
Разработка программного обеспечения более сложна, многообразна и непредсказуема, чем конвейерное
производство типовых моделей.
Непонимание между заказчиком и разработчиком требует создания единого словаря терминов
разрабатываемой информационной системы. У нас такой глоссарий системы представляет собой продукт
совместной разработки системного аналитика и проектировщика. С учетом того, что модели ТЗ и ТП
создаются с помощью CASE-инструментария Rational Rose, мы используем возможность
автоматизированного управления глоссарием, который находится в отдельной модели, доступной по сети всей
команде. Только один человек добавляет или модифицирует данные глоссария, остальные же автоматически
получают его текущую версию при работе со своими моделями. Эта возможность обеспечивается за счет
синхронизации информации в разрабатываемой модели (\\Project.mdl) и глоссария, встроенного "по ссылке" в
модель, но в то же время существующего отдельно (\\Glossary.cat). Благодаря этому становится реальной
10
параллельная работа системных аналитиков и проектировщиков при централизованном управлении
глоссарием и последовательной обработке запросов на его изменение (рис. 3).
Рис. 3. Работа с глоссарием
Для разделения информационных систем на модули используется множество методов - от описания
предметной области на английском языке (при этом существительные станут классами, а глаголы их
методами), до практики использования CRC-карт (Class-Responsibility-Collaborator - идентификация объектов
информационных систем, меры их "ответственности" и механизма взаимодействия). Наше решение зависит от
требований заказчика, штатной структуры компании и функциональных обязанностей служащих. При этом
обеспечивается максимальная интеграция с уже существующим программным обеспечением;
автоматизируются только те участки, в которых возникла необходимость и которые реально переработать за
установленные сроки и в конкретных условиях, остальное же остается "как есть" и разрабатываются
"переходники" для связи между "новыми" и "старыми" модулями.
Среди проблем собственно кодирования, следует выделить нежелание использовать компоненты сторонних
производителей; между тем, часто дешевле купить готовый модуль, чем разработать, протестировать и
внедрить собственный. При написании кода также могут использоваться готовые программные конструкции,
так называемые "паттерны" (design pattern). Последняя версия Rational Rose XDE поддерживает паттерны и
интегрирует их с Visual Studio .Net.
Хорошим проектным решением является стандарт на оформление программных форм, нормативы на
количество и размеры информационных и управляющих элементов, характеристики цветовой гаммы и т.п.
Помочь в данном случае может стандартный репозиторий программных форм. Кроме того, программный код
обязательно оформлять с учетом так называемых "правил кодирования", приняв соглашение по
форматированию, названиям объектов, механизмам использования памяти и обработки ошибок и т.п. Нашей
организации разработать полноценный стандарт кодирования еще предстоит, поэтому пока для нужд
непосредственно программирования используется репозиторий объектов. Сотрудник, ответственный за
техническую поддержку репозитория, модифицирует его с учетом изменяющихся требований по
функциональности и эффективности форм. Кроме того, в связи с использованием метода round-trip engineering
(синхронизация между кодом и моделью в обоих направлениях) с помощью RoseDelphiLink_3_2, разработано
положение о документировании программного кода, цель которого - автоматическое получение документации
через шаблоны Rational SoDA. В перспективе будет использоваться инструментарий компании BoldSoft,
средства которого вошли недавно и в Borland Delphi7 Architect Studio.
Ни один заказчик не станет читать ТЗ на две сотни страниц, но лучше иметь избыточную и плохо
структурированную информацию, чем не иметь ее вовсе. В [3] приводится график сравнения ее
разновидностей - на первом месте по эффективности стоит живое общение, а далее следуют телефонная связь,
электронная почта, видео- и аудиоконференции, и, наконец, бумажная документация (рис. 4).
11
Рис. 4. Эффективность различных видов коммуникаций
Мы решили задачу автоматизированного создания и модификации ТЗ и ТП за счет использования шаблонов
Rational SoDA. При этом из моделей Rose формируются готовые файлы в формате Word, соответствующим
образом оформленные и готовые для согласования (рис. 5). Таким образом, достигается главная цель налаживается взаимодействие удаленных друг от друга участников проектной команды, а ее создание не
является обременительным процессом.
Рис. 5. Принцип работы автодокументирования
И последний вопрос - тестирование, которому по-прежнему уделяется мало внимания. Между тем, сохраняет
свою актуальность мнение, высказанное в [1]: 1/3 времени проекта должно занимать планирование, 1/6 -
12
написание программ, 1/4 - тестирование компонентов и предварительное системное тестирование, 1/4 системное тестирование при наличии всех компонентов. В нашей организации имеются планы по
использованию средств типа Ghost, TestComplete, систем сбора дефектов (Rational ClearQuest), программ
определения утечки памяти, "охват" кода и скоростные параметры функций (Rational Purify, PureCoverage и
Quantify), но из-за недооцененности этих проблем тестирования руководством, серьезных инвестиций в
данную область пока нет. Одним из показателей зрелости ИТ-компании, как известно, является наличие у нее
стандарта тестирования, где представлена функциональная модель тестирования, определены сроки, роли и
обязанности участников, изготовлены тестовые классы, подсистемы, скрипты, инструменты, имеется
соответствующая документация.
Однако технике RUP присущи и ограничения: "вольность" при трактовке формулировок и концепций, обилие
документации и проработка только этапа моделирования бизнес-процессов. Поэтому в случае ориентации
разработки на быстрый результат, относительной легкости проекта и отсутствия проблем по его
сопровождению (как у Web-проектов), лучше, возможно, подходят "быстрые" методологии (например,
экстремальное программирование). RUP позволяет справляться с безнадежными проектами: такой
"недостаток", как обилие документации, превращается в достоинство, позволяющее четче определить роли и
обязанности участников. Проекты тянут ко дну, в основном, административные проблемы, а это решается
обычно "бумажным" путем.
Литература
1. Ф. Брукс. Мифический человеко-месяц. М.: Символ, 2001
2. Э. Йордан. Путь камикадзе. М.: Лори, 2001
3. А. Коуберн. Каждому проекту своя методология, TR 99.04, 1999, Oct.
http://www.crystalmethodologies.org/articles/mpp/methodologyperproject.html, перевод:
http://www.maxkir.com/sd/methyperproject_RUS.htm
Тезисы лекции №2 ERP-система и примеры бизнес-приложений ERP-систем
http://ru.wikipedia.org/wiki/ERP
ERP-система (англ. Enterprise Resource Planning System — Система планирования ресурсов
предприятия) — это интегрированная система на базе ИТ для управления внутренними и внешними
ресурсами предприятия (значимые физические активы, финансовые, материально-технические и человеческие
ресурсы). Цель системы — содействие потокам информации между всеми хозяйственными подразделениями
(бизнес-функциями) внутри предприятия и информационная поддержка связей с другими предприятиями.
Построенная, как правило, на централизованной базе данных, ERP-система формирует стандартизованное
единое информационное пространство предприятия[1].
Системы управления предприятием класса ERP предназначены обеспечить полную прозрачность бизнеспроцессов, сведение к минимуму неходовых позиций товара, рост оборачиваемости продуктов и
максимальную эффективность использования торговой площади. Например, внедрение системы управления
предприятием ERP класса Oracle Retail для автоматизации розничной торговли обеспечивает учет и анализ
ключевых бизнес-процессов:
 Управление ассортиментной матрицей
 Управление ценообразованием
 Управление производством
 Управление запасами
 Финансовый, бухгалтерский, налоговый учеты
 Планирование и анализ маркетинговых мероприятий
Oracle Retail является автоматизированной системой управления предприятия ERP-класса,
разработанной и адаптированной непосредственно для розничной торговли. Данная система предназначена
для автоматизации управления розничного предприятия любого размера: от одиночного магазина (convenience
store) или универмага (Department Store) до федеральной розничной сети гипермаркетов (hypermarket).
Система ERP
Новым этапом в развитии и внедрении систем управления предприятием, основанных на MRP II, стала
Enterprise Resource Planning System (ERP). ERP представляет собой интегрированный программный продукт,
позволяющий управлять дистрибуцией, логистикой, запасами, доставкой, бухгалтерским учётом.
Среди основных достоинств ERP — легкость установки, настройки и эксплуатации. Инструменты ERP
отличаются многофункциональностью и гибкостью. Системы ERP позволяют не только управлять ресурсами
компании, но и работать с другими областями ее деятельности: кадровой, партнерской и клиентской базами,
бухгалтерией и финансовой отчетностью.
13
Цель систем MRP и ERP — содействие обмену данными между всеми подразделениями внутри компании, а
также информационная поддержка взаимосвязи с другими предприятиями. Как правило, ERP системы
строятся на централизованной базе данных и формируют единое стандартизированное информационное
пространство организации. Продукт ERP направлен на максимальное удовлетворение потребностей
предприятия в сфере управления.
Концепция ERP
Исторически концепция ERP стала развитием более простых концепций MRP (Material Requirement
Planning — Планирование материальных потребностей) и MRP II (Manufacturing Resource Planning —
Планирование производственных ресурсов). Используемый в ERP-системах программный инструментарий
позволяет проводить производственное планирование, моделировать поток заказов и оценивать возможность
их реализации в службах и подразделениях предприятия, увязывая его со сбытом. Функции ERP-систем
В основе ERP-систем лежит принцип создания единого хранилища данных, содержащего всю корпоративную
бизнес-информацию и обеспечивающего одновременный доступ к ней любого необходимого количества
сотрудников предприятия, наделённых соответствующими полномочиями. Изменение данных производится
через функции (функциональные возможности) системы. ERP-система состоит из следующих элементов:
 модель управления информационными потоками (ИП) на предприятии;
 аппаратно-техническая база и средства коммуникаций;
 СУБД, системное и прикладное ПО;
 набор программных продуктов, автоматизирующих управление ИП;
 регламент использования и развития программных продуктов;
 IT-департамент и обеспечивающие службы;
 собственно пользователи программных продуктов.
Основные функции ERP систем:
 ведение конструкторских и технологических спецификаций, определяющих состав производимых
изделий, а также материальные ресурсы и операции, необходимые для их изготовления;
 формирование планов продаж и производства;
 планирование потребностей в материалах и комплектующих, сроков и объёмов поставок для
выполнения плана производства продукции;
 управление запасами и закупками: ведение договоров, реализация централизованных закупок,
обеспечение учёта и оптимизации складских и цеховых запасов;
 планирование производственных мощностей от укрупнённого планирования до использования
отдельных станков и оборудования;
 оперативное управление финансами, включая составление финансового плана и осуществление
контроля его исполнения, финансовый и управленческий учёт;
 управление проектами, включая планирование этапов и ресурсов
Отличие между ERP-системами и системами электронного документооборота (СЭД) в том, что, как правило, в
ERP документы являются машино-читаемыми, и они не «ведутся», а «проводятся» — уже после того, как они
осуществят свой жизненный цикл, то есть были созданы, обсуждены, проверены, согласованы, утверждены
и т. д. А СЭД осуществляет поддержку такого жизненного цикла человеко-читаемых документов на
предприятии.
Особенности внедрения
Классические ERP-системы, в отличие от так называемого «коробочного» программного обеспечения,
относятся к категории «тяжёлых» программных продуктов, требующих достаточно длительной настройки для
того, чтобы начать ими пользоваться. Выбор ERP-системы, приобретение и внедрение, как правило, требуют
тщательного планирования в рамках длительного проекта с участием партнёрской компании — поставщика
или консультанта. Поскольку ERP-системы строятся по модульному принципу, заказчик часто (по крайней
мере, на ранней стадии таких проектов) приобретает не полный спектр модулей, а ограниченный их комплект.
В ходе внедрения проектная команда, как правило, в течение нескольких месяцев осуществляет настройку
поставляемых модулей.
Достоинства
Применение ERP-системы позволяет использовать одну интегрированную программу вместо нескольких
разрозненных. Единая система может управлять обработкой, логистикой, дистрибуцией, запасами, доставкой,
выставлением счетов-фактур и бухгалтерским учётом.
Реализуемая в ERP-системах система разграничения доступа к информации предназначена (в комплексе с
другими мерами информационной безопасности предприятия) для противодействия как внешним угрозам
(например, промышленному шпионажу), так и внутренним (например, хищениям). Внедряемые в связке с
14
CRM-системой и системой контроля качества, ERP-системы нацелены на максимальное удовлетворение
потребностей компаний в средствах управления бизнесом.
Недостатки
Основные сложности на этапе внедрения ERP- систем возникают по следующим причинам:
 Недоверие владельцев компаний высокотехнологичным решениям, в итоге — слабая поддержка
проекта с их стороны, что делает осуществление проекта труднореализуемым.
 Сопротивление департаментов в предоставлении конфиденциальной информации уменьшает
эффективность системы.
Множество проблем, связанных с функционированием ERP, возникают из-за недостаточного инвестирования
в обучение персонала, а также в связи с недоработанностью политики занесения и поддержки актуальности
данных в ERP.
Ограничения:
 Небольшие компании не могут позволить себе инвестировать достаточно денег в ERP и адекватно
обучить всех сотрудников.
 Внедрение является достаточно дорогим.
 Система может страдать от проблемы «слабого звена» — эффективность всей системы может быть
нарушена одним департаментом или партнёром.
 Проблема совместимости с прежними системами.
Существует заблуждение, что иногда ERP сложно или невозможно адаптировать под документооборот
компании и её специфические бизнес-процессы. В действительности, любому внедрению ERP-системы
предшествует этап описания бизнес-процессов компании, чаще всего сопряжённый с последующим этапом
бизнес-реинжиниринга. По сути ERP-система являет собой виртуальную проекцию компании.
[Список ERP-программ — Список бесплатных, открытых и коммерческих систем планирования
ресурсов предприятия (ERP)
 SSTD — Единая система решения корпоративных задач
 EAM — системы управления основными фондами предприятия
 MES — системы оперативного (цехового) управления производством/ремонтами
 WMS — системы управления складами
 CRM — системы управления взаимоотношениями с клиентами
 SCM — системы управления цепочками поставок
 CMMS — компьютеризированные системы управления техническим обслуживанием
 HRM — Система управления персоналом (кадрами)
 CTMS — Система управления контейнерным терминалом
 ECM — Системы управления информационными ресурсами предприятия
 Документ изменен приказом номер 1975 от 31.05.2011
1. Примеры ERP-систем.
№1: Холдинг Nisa-Today’s (Великобритания) является крупным дистрибутором для оптовых и
розничных компаний. Он объединяет более 674 розничных компаний, которые совместно управляют более
5000 магазинов и 300 оптовых компаний с 320 складами. Nisa-Today’s поставляет 1.5 миллиона упаковок
товара в неделю для 5000 получателей по территории всей Великобритании. Ежегодная выручка 2 миллиарда
долларов, Результаты внедрения Oracle Retail
Каждый магазин имеет возможность проводить точные прогнозы с точностью до товаров и дней,
используя решений Oracle Retail Demand Forecasting.Создана гибкая, масштабируемая и проверенная
платформа для работы решений Oracle Retail Автоматизированы ключевые бизнес-процессы, создана основа
для эффективного управления товародвижением и процессов прогнозирования.
С использованием решения Oracle Retail Invoice Matching повышена эффективность процесса контроля
входящих инвойсов, что повышает точность контроля входящих инвойсов и скорость обнаружения и
обработки расхождений
Примеры ERP-систем. №2: Fresh & Easy - новая сеть «магазинов у дома» в Калифорнии (США) Дата
образования – 2007 год Количество магазинов - 25+ Планы развития – 200 магазинов за 2-3 года.
Особенности проекта – ориентац ия по свежие и экологические продукты.
Описание проекта Особенностью данного проекта автоматизации было то, что это совершенно новая
сеть розничных магазинов. Исходя из этого, руководство компании решило выбрать технологииOracle, как
основу своей IT-стратегии. На текущий момент вся программная поддержка бизнеса осуществляется на
программных продуктах Oracle Retail,Oracle Retail Optimization&Planning, а также частях Oracle EBS.
15
Установленные модули: Oracle Retail Merchandising Oracle Retail Price Management Oracle Retail
Category Planning Oracle Retail Invoice Management Oracle Retail WMS Oracle Retail SIM Oracle Financials
Oracle HR Oracle Manufacturing Oracle Technology Stack
Примеры ERP-систем. №3: Woolworths– сеть супермаркетов в ЮАР (Кейптаун) Количество
магазинов – 300+ Оборот в год – более 2,3 млрд. долларов Количество сотрудников – 12000.
Результаты внедрения Oracle Retail: Установлена полная система приложений Oracle Retail
направленных на улучшение контроля товародвижения и снижения потерь. Централизованы процессы
управления товарными запасами, контроля поставок и инвойсов, распределения товаров по магазинам и
управления ценообразованием для более плотного контроля операций и улучшения удовлетворенности
покупателей Улучшено управление цепочкой поставок, управление финансами, управление промо-акциями и
распродажами, управление прибыльностью.
Системы PDM - Product Data Management (PDM)— система управления данными об изделии. Система
PDM является неотъемлемой частью PLM-системы. Задачи Системы PDM - управление хранением данных и
документами, управление потоками работ и процессами, управление структурой продукта, автоматизация
генерации выборок и отчетов, механизмы авторизации.
Системы PLM - Product Lifecycle Management (PLM) - это система управления инженерной технической
информацией на протяжении всего жизненного цикла изделия. Это решение, которое обеспечивает
управление данными и информацией об изделии, а так же всех вязанных с изделием процессах на всем
жизненном цикле от проектирования и производства до завершения эксплуатации. Информация об объекте,
содержащаяся в PLM-cистеме, является цифровым макетом этого объекта.
ПРИМЕР. Система "Союз-PLM" представляет собой программный комплекс, выполненный в
новаторской архитектуре, предназначенной для решения различных задач управления инженерными данными
в области машиностроения, приборостроения, архитектуры, строительства и смежных с ними областях. Союз
–PLM обеспечивает:
 электронное согласование и утверждение документов
 управление коллективным моделированием в 3D САПР
 автоматизированное оформление регламентированных документов
 интеграция с ERP системами
 управление жизненным циклом изделия
 автоматизация бюро технической документации («электронный архив»)
ВОЗМОЖНОСТИ Системы "Союз-PLM":
Работа в географически распределённой среде
Благодаря системе упреждающего кэширования "Союз-PLM" расходует
минимум сетевого трафика для своей работы, что даёт превосходные показатели при
работе в географически распределённой среде. Например, работа с САПР под
управлением "Союз-PLM" будет комфортной даже вне предприятия (аэропорт,
Интернет-кафе, "на дому").
Разграничение и управление доступом
Реализованная в "Союз-PLM" ролевая система управления доступом,
способная действовать в масштабе проектов (групп объектов), индивидуально для
информационных объектов, с учётом их вида (шаблона), выборочно для некоторых
атрибутов, позволяет организовать работу с инженерными данными адекватно
методикам, используемым на предприятии. Данные о документах, изделиях и их
характеристиках, пользователях, ролях размещены в защищённых хранилищах и
при необходимости могут быть не только "обезличены", но и зашифрованы.
Доступность информации для повседневной работы и принятия оперативных решений
Механизм рабочей среды позволяет представить PLM-информацию в виде
наиболее удобном для текущей работы пользователя в зависимости от его
специализации. Например, в рабочей среде можно отобразить информацию об
изделии в виде дерева, разложить содержимое контейнера по видам документов,
сделать ссылки на текущие проекты, отобразить перечень workflow-задач, в которых
необходимо принять участие.
Коллективная работа в САПР
16
Современные системы моделирования, например, такие как Autodesk
"Inventor" или система оформления 2D-документации "AutoCAD Mechanical",
используемые под управлением единой информационной системы "Союз-PLM",
приобретают новое качество - становятся мощной системой проектирования. В
сочетании с PLM резко возрастает эффективность применения САПР за счёт
добавления к САПР возможностей по хранению
Тезисы лекции №3 Мировой рынок ERP-систем
К классу ERP-систем (аббревиатура от Enterprise Resource Planning — планирование и управление ресурсами
предприятия) относится управленческий «софт», который обеспечивает интегрированность автоматизации
управленческих функций и рабочих процессов в рамках единой корпоративной информационной системы, т.е.
позволяет осуществить «сквозную» информатизацию деятельности компании.
По оценкам AMR Research, объем продаж ERP-систем в мире в 2005 г. должен превысить $24 млрд. В 2004 г.
мировой рынок ERP-систем продемонстрировал впечатляющие темпы роста — 14%, значительно превзойдя
все прогнозы аналитиков. Правда, столь высокий показатель роста в известной мере связан с укреплением
европейской валюты на фоне падения доллара. В 2005 финансовом году, по оценкам аналитиков, рост этого
рынка должен замедлиться (не более 3%) в связи с его неизбежным насыщением. Впрочем, в 2006-2009 гг.
рост рынка должен, по прогнозам, составить 6-7% в год.
В последние годы на рынке корпоративных информационных систем заметно активизировались процессы
консолидации. Процессы слияния и поглощения ведут к изменению расстановки сил среди наиболее крупных
игроков. Отмечается также ужесточение конкуренции между основными игроками по всем направлениям, в
том числе между теми компаниями, которые ранее были «разнесены» по разным сегментам рынка (например,
крупного бизнеса и сегмента среднего и малого бизнеса). Лидеры активно вторгаются в рыночные ниши
«соседей» и серьезно наращивают там свои продажи.
Источник: Консалтинг-Центр "ШАГ"
Лидеры мирового рынка ERP-систем
Около 75% рынка управленческих систем занимает пятерка лидеров: SAP, Oracle (включая PeopleSoft),
Sage Group, Microsoft Business Solutions (MBS), и SSA Global (купившая Baan).
Ведущим ERP-вендором традиционно считается немецкая компания SAP AG, которая в 2004 г. заняла 40%
мирового рынка ($9,37 млрд.), продемонстрировав 17% рост доходов, а в Европе ее доля превысила 50%. По
некоторым данным, доход компании в 2005 календарном году составил $10,47 млрд., а рост дохода по
сравнению с 2004 г. — 12%. Стратегическая цель компании — сохранить лидирующее положение в продажах
малому и среднему бизнесу. В 2005 г. SAP, разработки которого пользуются наибольшей популярностью в
Европе, планировал увеличивать доходы, в первую очередь за счет Америки и Азиатско-Тихоокеанского
региона.
Кроме этого, к 2007 г. SAP, сделавший ставку на реализацию сервисно-ориентированной архитектуры,
планирует завершить разработку нового поколения корпоративных информационных систем — сервисной
архитектуры предприятия (Enterprise Services Architecture). SAP также рассчитывает превратить свою
технологическую платформу NetWeaver в платформу для автоматизации бизнес-процессов, которую
пользователи могут адаптировать под свои потребности. Это также должно облегчить интеграцию продуктов
от независимых разработчиков с продуктами SAP.
17
Вторая позиция на рынке ERP-систем принадлежит американской компании Oracle, которой удалось
существенно увеличить свою долю благодаря поглощению в 2004 г. компании PeopleSoft. По оценкам AMR
Research, в начале 2004 г. доля Oracle ограничивалась 13% мирового рынка (в Европе — чуть более 1%). В
результате же приобретения PeopleSoft (12% мирового и 12,5% европейского рынков ERP-систем) на долю
объединенной компании к началу 2005 г. пришлось уже 22% мирового и 13% европейского рынков (объем
продаж в 2004 г. составил $5,35 млрд.). Однако вследствие процесса слияния суммарная доля этих двух
компаний упала за 2004 г. на 2%. Тем не менее, сегодня Oracle считается одним из самых перспективных
игроков мирового рынка ERP-систем. Стремясь добиться конкурентных преимуществ, компания
концентрирует усилия на снижении общей стоимости своего программного обеспечения для потребителей за
счет улучшения интеграции, уменьшения времени инсталяции, снижения административных расходов и
повышения простоты использования.
Третью позицию на рынке ERP-систем занимает английская компания Sage Group. Доходы этой компании в
2004 г. выросли на 38% и составили $1,24 млрд., а доля рынка — 5%.
Успешное продвижение после приобретения Navision демонстрирует Microsoft Business Solutions (MBS) —
подразделение американской корпорации Microsoft. На текущий момент MBS принадлежит 4% мирового
рынка. В 2004 г. эта компания увеличила свою выручку в этом сегменте ИТ-продуктов и услуг на 14%.
Расширяясь, Microsoft проникает в целевые для SAP сектора рынка, увеличивая конкуренцию. В то же время в
Европе присутствие компании оценивается как весьма скромное — менее 1%. Так, в секторе малого и
среднего бизнеса, на который преимущественно ориентированы ERP-продукты Microsoft, решения MBS,
предназначенные для небольших компаний, вытесняются менее дорогими решениями Sage Group, а средний
бизнес Западной Европы в большей степени предпочитает продукты SAP.
Российский рынок ERP-систем Общая характеристика рынка ИКТ
Рынок ERP-систем является частью информационно-коммуникативной отрасли, которая, в свою очередь,
объединяет 2 основных сектора: Связи и Информационных технологий. При этом отрасль
Информационные технологии объединяет всю совокупность предприятий и организаций, обслуживающих
деятельность других предприятий и организаций в части услуг по техническому и программному
обеспечению (разработка программного обеспечения, создание и обработка баз данных, создание
и обслуживание локальных компьютерных сетей, услуги сети интернет, техническое обслуживание и ремонт
вычислительной техники).
Данные об объемах производимой продукции в отрасли и, в частности, в сегменте Информационных
технологий, свидетельствуют об устойчивых тенденциях роста на рынке в течение последних 4-5 лет.
Министр информационных технологий и связи РФ на всероссийском совещании по итогам работы отрасли в
2004 г. сообщил, что в 2004 г. зафиксирован рост доли отрасли ИКТ в ВВП страны с 3,2% в 2003 году до
4,8%. Объем рынка связи в 2004 г. вырос на 37% и составил 540 млрд.руб., а объем российского рынка ITуслуг и технологий увеличился на 20% и составил порядка 255,6 млрд.руб. В 2005 г. доля отрасли в ВВП
достигла 5%, в среднем по рынку темпы роста относительно 2004 г. составили от 27 до 40%.
Источник: Министерство информационных технологий и связи РФ
Темпы развития ИКТ-рынка обгоняют рост ВВП. Это означает, что тенденции насыщения, характерные для
мирового рынка, не типичны для России, которая информатизируется ускоренными темпами. Ускоренные
темпы роста являются следствием низкого уровня информатизации основных сфер экономики.
18
Рынок ERP-систем
Западные ERP-системы (системы автоматизации управления предприятием) появились российском рынке еще
в начале 90-х. Первой открыла свое российское представительство компания SAP AG. За ней потянулись и
другие западные ERP-разработчики и консалтинговые компании. Уже в середине 90-х гг. были открыты
несколько представительств и заключены партнерские соглашения с рядом российских компаний, а к концу
90-х на российском рынке присутствовали почти все ведущие западные ERP-производители. После
нескольких лет экспериментов и неудач, связанных с освоением "российской специфики" (слабая
стандартизация и регламентация бизнес-процессов, своеобразный бухучет и частая смена регулирующего его
законодательства) начались достаточно успешные внедрения западных систем, составивших серьезную
конкуренцию отечественным "Парусу" и "Галактике".
Конец 90-х- начало 2000-х г.г. можно охарактеризовать как эпоху бурной, "догоняющей" информатизации
основных сфер российской экономики, когда отечественный ИТ-рынок, вопреки мировым тенденциям,
развивался ускоренными темпами. Однако уже в 2004 г. отчетливо обозначилось снижение темпов роста
российского ИТ-рынка. Это заставило основных игроков, как отечественных, так и зарубежных, усиливать
свое присутствие в наиболее перспективных и малонасыщенных сегментах. Одним из таких наиболее
привлекательных сегментов оказался рынок ERP-систем.
Источник: IDC, 2005
В настоящее время лидирующее положение на рынке занимает семерка компаний, доля которых, по итогам
2004 года , составила 93% от всего рынка ERP.
Источник: IDC, 2005
Согласно данным интернет-издания GAAP.RU по состоянию на 2004 г. количество отраслевых решений
лидеров в области разработки ERP-систем распределялось следующим образом:
Значительную часть доходов на рынке ERP составили прямые продажи. В то же время, отмечен заметный
рост удельного веса доходов от продаж лицензий, поддержки внедренных систем и ИТ-консалтинга. Продажи
лицензий внесли наибольший вклад в динамику 2004 года, а рост доходов от технической поддержки
постоянно растущей клиентской базы особенно заметен был у тех компаний, которые давно работают на
российском рынке и сумели сформировать широкий круг заказчиков.
19
Следует отметить, что внедрение своих продуктов на российских предприятиях зарубежные разработчики
отдают, как правило, "на откуп" российским бизнес-партнерам, специализирующимся на ИТ-консалтинге. В
числе лидеров российского рынка услуг по внедрению ERP пакетов (по состоянию на 2004 г.) можно
выделить:
 ООO "Альфа Интегратор" - "БААН Евразия" - ERP пакет Baan
 Columbus IT Partner Russia - ERP пакет MBS Axapta
 ООО "САП СНГ и страны Балтии" - ERP пакет SAP R/3
 "Oracle СНГ" - ERP пакет Oracle E-Business
Последнее исследование IDC отмечает рост числа отечественных компаний, предлагающих собственные
разработки. Так, в 2005 г. впервые в отчёт IDC вошла российская 1С, поставляющая пакет "1С Предприятие
8.0", соответствующий мировым стандартам и классификации IDC. В то же время, в результате слияний и
поглощений численность западных компаний на российском рынке в последние годы сокращалась.
Источник: IDC, 2005
Существенной характеристикой современного рынка ERP-систем является динамика спроса со стороны
заказчиков различных "весовых категорий". Как отмечают эксперты, российский ERP-рынок во многом
воспроизводит динамику мирового рынка: большинство отечественных и зарубежных поставщиков,
удовлетворив в значительной мере спрос на автоматизацию со стороны крупных предприятий, концентрирует
сегодня усилия на разработке ПО для перспективного, быстро растущего сектора среднего бизнеса. Сегодня
над предложениями для средних предприятий активно работают компании, для которых ранее была
характерна работа в основном с крупными и очень крупными заказчиками (SAP, Oracle). Выходят в сегмент
средних предприятий и те из разработчиков, кто совсем недавно основное внимание уделял решениям для
малых компаний ("1С"). Вместе с тем, как считает аналитик IDC Елена Семеновская, спрос ERP-системы со
стороны крупных отечественных предприятий далеко не исчерпан: "Хотя крупные предприятия и были
первыми покупателям ERP-систем, многие из них, пройдя через слияния и реорганизации, будут
совершенствовать имеющиеся системы или устанавливать новые."
Тенденции и прогнозы
Остановимся на основных прогнозах и тенденциях отечественного рынка ПО управления предприятием.
 Согласно исследованию, проведенному агентством Gartner по заказу SAP, высокий спрос со стороны
российских компаний на ERP-системы сохранится в 2006 г. Заметный подъем экономики в
большинстве отраслей и политическая стабилизация будут стимулировать интерес как
зарубежных, так и отечественных инвесторов к долгосрочным вложениям в производство.
 Важным фактором востребованности ERP-систем являются идущие процессы консолидации внутри
отраслей: вновь создаваемые группы компаний и холдинги остро нуждаются в программном
обеспечении, позволяющем интегрировать разнородные информационные системы в единый
управленческий механизм.
 Подъем спроса на ПО для корпоративного управления ожидается со стороны компаний, готовящихся к
размещению акций на западных фондовых рынках и стремящиеся повысить инвестиционную
привлекательность за счет прозрачного для инвесторов ведения бизнеса. По данным экспертов, в 2006
г. первичное размещение акций (IPO) проведут более 20 российских компаний, что послужит
дополнительным импульсом для развития ERP-рынка и росту спроса на системы, поддерживающие
западные стандарты финансовой отчетности. Из тех же соображений прозрачности значительный
спрос на ERP-системы формируют на российском рынке филиалы и представительства западных
компаний.
20

По оценкам IDC, в качестве потребителей ERP-систем значительным потенциалом роста обладают
такие отрасли, как розничная торговля, банковская сфера и государственный сектор. Темпы роста этих
сегментов будут намного опережать темпы роста российского рынка ERP в целом, которые вплоть до
2009 г. ежегодно будут составлять 26% . В качестве основного кандидата на роль "локомотива" рынка
ERP-систем рассматривается государственный сектор. Сегодня государственные организации
проявляют повышенный интерес к системам корпоративного управления. Заметно активизировались
действия государства в рамках программы "Электронная Россия" (2002-2009 г.г.), широкому
разворачиванию которой препятствовало проведение административной реформы в 2003-2004 г.г. В
2005 г. начато создание ряда крупных межведомственных информационных систем, таких, как
системы пограничного и миграционного контроля, система обеспечения выпуска паспортов нового
поколения. Ожидается проведение крупных ИТ проектов в таможенных и налоговых органах и других
государственных структурах. Стоимость готовящегося проекта РТКомм.ру в федеральном
казначействе оценивается в $140 млн., а стоимость проекта внедрения ERP-системы для
Министерства финансов РФ может составить $0,5-1 млрд.
 В ближайшее время на рынке ERP-систем ожидается рост числа отечественных программных средств
управления предприятием, в которых реализуется дополнительная Интернет-функциональность
(CRM-функции, управление логистическими цепочками и др.). Работами в данном направлении
занимаются, в частности, компании "Парус", "Галактика", "Компас" и др. Сегодня идея управления
процессами, выходящими за рамки отдельного предприятия и охватывающими более широкую
кооперацию потребителей и поставщиков, не только вызывает интерес у возможных заказчиков, но и
успешно претворяется в жизнь. По данным Консалтинг-Центра "ШАГ", прецеденты
функционирования автоматизированных систем управления межфирменной кооперацией (так
называемые ERP-2) на базе отечественного ПО уже имеют место в отдельных секторах розничной
торговли.
 Два-три года назад на рынке наметилась тенденция к ужесточению конкуренции среди компаний,
способных работать на внедренческий результат, в то время как "конкуренция" близких по
функционалу программных продуктов все более сходила на нет. При выборе партнера все большее
внимание заказчики уделяют наличию у компании-консультанта опыта успешной реализации
аналогичных проектов. Эксперты полагают, что в 2006-м эта тенденция только усилится.
 Продолжается смещение спроса от универсальных систем управления в сторону вертикальных,
учитывающих особенности отрасли и содержащих типовые решения ее задач. Сегодняшних
клиентов интересуют прежде всего проверенные отраслевые решения, используемые аналогичными
предприятиями не только в мире, но и в России. Риски внедрения такого ПО значительно ниже, чем
при внедрении стандартных ERP-систем. Соответственно, начинается и будет продолжаться
отраслевая специализация компаний-консультантов, имеющих опыт большого количества внедрений в
отрасли и глубоко понимающих задачи того или иного бизнеса. Сегодня специализированные
отраслевые решения востребованы в оптовой и розничной торговле, пищевой промышленности,
машиностроении, финансовых компаниях, телекоммуникациях, энергетике, на горнодобывающих
предприятиях и во многих других отраслях.
 По мере увеличения числа внедрений закономерно растет спрос на поддержание уже
функционирующих систем. Казалось бы, рыночная ниша для компаний, оказывающих услуги
поддержки информационных систем, должна расширяться. В реальности же этого не происходит в
силу того, что за время внедрения во многих компаниях на базе ИТ-подразделений формируются
собственные профессиональные команды, способные самостоятельно справляться не только с
поддержкой информационных систем, но и с их адаптацией к меняющимся условиям рынка и
запросам бизнеса.
 По мнению аналитиков IDC, одним из узких мест, сдерживающих развитие рынка ERP-систем в
России, остается нехватка квалифицированных кадров: консультантов, программистов,
конструкторов бизнес-процессов.
Лидеры российского рынка ERP-систем
SAP AG
Компания SAP AG пришла в Россию в 1992 г., и за годы присутствия создала целую инфраструктуру
продвижения своей системы R/3 на российском рынке, проводя регулярные тематические семинары,
вкладывая средства в обучение консультантов и накапливая опыт в различных отраслях.
На 2005 г. партнерская сеть SAP в России насчитывает более 30 компаний и охватывает 6 городов. Согласно
данным за 9 месяцев 2005 г., доля в общем бизнесе SAP, которую приносит представительство SAP в странах
СНГ, увеличилась с 2% до 4% по сравнению с аналогичным периодом прошлого года.
21
Наибольший доход компании SAP в нашей стране приносят, в первую очередь, нефтегазовые компании, а
также электроэнергетика, транспортная отрасль и машиностроение. В последнее время SAP в России
активизировался в финансовом секторе, телекоммуникационных компаниях и розничном бизнесе.
Стоимость поставки SAP R/3 на 50 рабочих мест составляет примерно $350000. Стоимость внедрения R/3, как
правило, в несколько раз превышает стоимость лицензий.
Oracle
Продвижением Oracle Applications в России занимается российское представительство корпорации Oracle Oracle CIS - через своих бизнес-партнеров. В настоящее время в России и СНГ реализовано 29 проектов по
внедрению ERP-системы Oracle Applications со средним количеством пользователей около 70.
По данным IDC за 2004 г., в России Oracle занимает 1-е место на рынке СУБД, 1-е место на рынке серверов
приложений и 2-е место на рынке систем управления предприятием.
Microsoft Business Solutions
Представительство Microsoft действует в России с ноября 1992 г., с июля 2004 г. - ООО "Майкрософт Рус".
MBS является одним из ведущих мировых поставщиков ERP-решений. Компания предлагает своим клиентам
целую линейку продуктов Axapta, Great Plains, Navision, Solomon, а также Microsoft CRM, предназначенных
для комплексной автоматизации прежде всего средних и малых предприятий.
В апреле 2000 г. на российском рынке ERP-систем для средних предприятий появилась локализованная
версия Axapta 2.1 (а уже в декабре 2001 г. — Navision Axapta 2.5), разработанная датской компанией Navision
a/s. Специально для розничных сетей, работающих в России, на базе ERP-системы Microsoft Axapta было
разработано отраслевое решение Axapta Retail.
Стоимость поставки и внедрения системы Axapta составляет несколько сотен тысяч долларов. В среднем
стоимость в расчете на одно рабочее место составляет €1600-2500. Соответственно, пакет на 20
одновременных пользователей будет стоить примерно €36 000-50 000.
Корпорация Галактика
На рынке с 1986 г. Доход в 2005 г. $24,7 млн. (на 16% больше, чем в 2004 г.) В 2005 г. выпустила на рынок
полнофункциональный комплекс бизнес-решений Галактика Business Suite, ядром которого является система
Галактика ERP. Согласно рейтингу, подготовленному "Эксперт РА", по итогам первого полугодия 2005 г.
корпорация "Галактика" занимает 10-е место среди крупнейших консалтинговых групп России.
Имеет отделения в Санкт-Перетбурге, Екатеринбурге и Самаре, официальных представителей в Тюмени,
Новокузнецке, Хабаровске и Владивостоке, а также центральные офисы в Минске, Киеве и Алматы.
По данным самой компании, 57% доходов в 2005 г. получено от оказания услуг, 43% — от поставки лицензий.
Наибольшая концентрация заказов в нефтегазовом комплексе (18,3%), машиностроении (18%) и связи
(12,7%); значительные доли имеют также химическая промышленность, транспорт, лесопереработка,
торговля, горнодобывающая промышленность и электроэнергетика.
Epicor Scala
Система Scala впервые была представлена на рынке СНГ в 1991 г. Scala СНГ стала первой среди компаний,
предлагающих программные средства и услуги по управлению бизнесом, финансами и производством на
территории СНГ и Восточной Европы. C 2004 г. компания стала частью корпорации Epicor, которая уже более
20 лет остается лидером в области интегрированных систем планирования корпоративных ресурсов (ERP),
управления взаимоотношениями с заказчиками (CRM) и управления цепочками поставок (SCM) для среднего
бизнеса во всем мире.
Абсолютные финансовые показатели работы в странах СНГ руководством Epicor-Scala не раскрываются;
структура доходов в этом регионе следующая: 47% — поддержка старых клиентов, 28% — консалтинг и 25%
— продажа лицензий. За 12 лет общее число заказчиков, использующих продукты Epicor и Scala, достигло
600, причем 70% из них эксплуатируют системы Scala.
1С
ЗАО "1С" было основано в 1991 г. По данным экспертов, в 2003 г. продажи компании составили $65 млн., в
первом полугодии 2004 г. — $40 млн.
Хотя компания традиционно не позиционирует свои решения как продукты класса ERP, в 2005 г. IDC впервые
включила ее в свое исследование, отмечая, что они полностью соответствуют мировым стандартам систем
ERP. За 2004 г. продажи "1С Предприятие: 8.0" выросли на 143%, а за январь-сентябрь 2005 г. — на 282% по
сравнению с аналогичным периодом 2004 г.
Широкое распространение продуктов 1С во многом обусловлено тем, что "1С" работает с пользователями
через самую разветвленную на компьютерном рынке СНГ партнерскую сеть.
"1С" не ограничивается продажей собственных разработок. Фирма — официальный дистрибьютор
программного обеспечения Miсrosoft, Novell, Symantec, Intel и других зарубежных фирм.
22
Оборот 1С в 2005 г. вырос на 42%. Продажи программного обеспечения на внутреннем рынке увеличились на
60%, мультимедиа — на 30%, а объем дистрибуции ПО западных вендоров вырос на 29%.
BAAN Eurasia
Компания Baan официально вышла на российский рынок в 1997 г. через компанию "БААН-Евразия".
Стоимость поставки и внедрения системы Baan для среднего предприятия (работа в системе 100-150
человек) оценивается в $600-800 тыс. По другой информации стоимость поставки лицензии Baan на 1
пользователя составляет $3000, а стоимость конкурентной лицензии (с ограничениями по
одновременному подключению к базе данных) — $6000. При этом стоимость внедрения Baan обычно
больше стоимости поставки в несколько раз. Мировой рынок информационных и
телекоммуникационных технологий
Структура и динамика мирового рынка ИКТ
Мировой рынок информационных и телекоммуникационных технологий (ИКТ) включает в себя сегменты
аппаратного обеспечения, программного обеспечения, ИТ-услуг, а также сегмент телекоммуникаций.
Сегодня объем мирового рынка ИКТ по величине затрат превысил $2,5 трлн. (данные Gartner). Большая его
часть приходится на телекоммуникационные услуги — почти $1,5 трлн. Около 25% общего объема было
потрачено в прошлом году на ИТ-услуги. Доля затрат на «железо» составила порядка 15%. Минимальный
показатель — 4% — составили затраты на программное обеспечение. В целом расходы на ИТ в мире (без
телекоммуникаций) в 2005 г. достигли $1 трлн. По прогнозам, в 2006 г. в структуре инвестиций сохранится
сложившаяся «расстановка сил».
Диаграмма 1.
Источник: Gartner
Прогнозы развития рынка выглядят достаточно оптимистичными, однако обращает на себя внимание
начавшаяся в 2005 г.тенденция к снижению темпов роста отрасли. Если, например, ИТ-затраты в секторе
розничной торговли в 2004 г. выросли на 6%, то с 2005 г. ожидаемый рост не превысит 5%. Видимо,
тенденция к небольшому снижению темпов роста продолжится и в 2006 г. В некотором смысле это указывает
на насыщение и «взросление» рынка. В 2006 г. объем затрат на ИТ в целом увеличится всего на 4% по
сравнению с показателями 2005 г. (прогноз Gartner).
Диаграмма 2.
Источник: Gartner
23
Одним из самых перспективных последние 2 года считается рынок малого и среднего бизнеса. В этом секторе
заметно увеличились объемы ИТ-расходов, в то время как крупные компании не спешили тратиться на новые
технологии. Уже в 2003 г. предприятия малого и среднего бизнеса только в США потратили на ИТ более $85
млрд. В 2004 г. малый и средний бизнес составил около 2/3 клиентов (31% доходов) компании SAP — лидера
рынка ПО, обслуживающего крупнейшие мировые компании (в том числе 80% списка Fortune-100). По
мнению аналитиков, внимание к нуждам малых и средних компаний принесет неплохие доходы тем вендорам,
которые появились здесь раньше других и научились работать с этими клиентами (например, IBM, HP и Dell).
Одним из важнейших факторов успеха в этом сегменте рынка оказывается надежная и эффективная
постпродажная поддержка.
В целом самыми заманчивыми для поставщиков ИТ-продуктов и услуг во всем мире остаются контракты
в государственном секторе, производственной и банковской сфере. Перспективными с точки зрения роста
расходов на ИТ аналитики называют также финансовый и телекоммуникационный рынки. Мировой
финансовый сектор предоставит широкие возможности для расширения бизнеса ИТ-вендоров за счет
построения единой ИТ-инфраструктуры и соблюдения новых регулятивных правил. С другой стороны,
энергетические компании и компании, работающие с природным газом, по мнению Forrester, склонны,
напротив, уменьшать ИТ-бюджеты.
Тезисы лекции №4 Критерии выбора ERP-систем для России
(литература: Леонид Отоцкий, leo@mmk.ru; Анатолий Савин, Savin@maginfo.net)
Центр АСУ ММК, Магнитогорск; Комплексные Системы , Магнитогорск
Данная статья посвящена вопросам внедрения на российских предприятиях современных интегрированных
систем управления (ИСУ) . Конкретно, речь пойдет о критериях выбора систем класса ERP , которые
могут быть полезны как для потенциальных потребителей таких систем , так и для поставщиков.
1. Классификация поколений автоматизированных систем управления [1].
1-e поколение:
а.использование индивидуальных моделей бизнес-процессов для отдельных предприятий или их типов;
б.использование плоских файлов (или иерархических СУБД) и 3GL, в стиле IBM 360/370.
Примеры : уникальные системы металлургических компаний USX и British Steel, работающие только на
конкретном предприятии.
2-е поколение:
а. использование типовой модели бизнес-процессов MRP/MRP II для любого типа предприятий;
б. см. пункт 1.б плюс использование собственных средств разработки класса 4GL.
Примеры : базовые системы компаний Computer Associates, SAP и Baan.
3-e поколение:
а. развитие модели ERP (п. 2а). Применение реляционных СУБД ведущих производителей (Oracle, Sybase,
Informix, Ingres и т.п.), основанных на международных стандартах SQL;
б. отказ от использования индивидуальных средств разработки (применение унифицированных средств,
основанных на SQL, включая типовые экранные формы, отчеты и т.д.);
в. переход от идеологии мэйнфреймов к идеологии «клиент/сервер» и распределенным базам данных.
Примеры : базовые системы от Oracle, ESI/Technology, IFS; адаптации новых версий систем 2-го
поколения в части использования некоторых возможностей типовых реляционных СУБД с сохранением
собственных средств разработки и поддержки.
4-е поколение:
а. перенос типовых функций, процедур, триггеров с уровня приложений на уровень СУБД (использование
возможностей нового поколения реляционных СУБД ведущих производителей);
б. использование средств автоматизации проектирования и программирования (CASE) для поддержки
«электронного проекта» на всех этапах его жизненного цикла;
в. дальнейшая стандартизация и специализация бизнес-функций с выделением в самостоятельные прикладные
модули средств поддержки хранилищ данных, OLAP и систем поддержки принятия решений;
г. использование GUI, включая Web интерфейс.
Примеры : новые разработки фирм Decade Financials и Alcie, полностью построенные на Designer/2000 и
Developer/2000; новые версии ERP систем от Oracle, ESI/Technology, IFS. Важно отметить, что начали
появляться отечественные разработки,ориентированные на технологию 4-го поколения - это системы К*3[7]
и БОСС КОРПОРАЦИЯ [8].
5-е поколение:
а. дальнейшая типизация метаданных, логических структур баз данных и описаний бизнес-функций на основе
стандартов STEP и CORBA (включая UML);
24







б. выделение независимых объектно-ориентированных подсистем управления данными о продукции, а также
технологий, основанных на стандартах STEP и CORBA (PDM системы 2-го поколения) [10];
в. создание репозитария стандартных компонентов бизнес-объектов и функций для «сборки» прикладных
систем и их «перекомпоновки» (для «реинжиниринга бизнес-процессов» при внедрении ERP системы );
г. выделение независимых объектно-ориентированных подсистем сервисного обслуживания и
администрирования, основанных на идеологии ORB и DCOM.
д. использование корпоративных и глобальных сетей для создания «виртуальных» производств и
предприятий.
Развитие систем 5-го поколения только начинается:
организован альянс Oracle с Metaphase и Sherpa с целью интеграции ERP системы Oracle c PDM
системами Metaphase и Sherpa;
компания Siemens Nixdorf разрабатывает интерфейс между ERP R/3 от SAP и PDM системой фирмы
Metaphase;
выделение самостоятельного PDM модуля из ERP системы фирмы IFS;
приобретение Baan компании ВА Intellegence - одного из производителей PDM систем ;
Более подробное описание эволюции Интегрированных Систем Управления приведено в работе [1].
2. Критерии выбора ERP-систем.
Критерий 1. Место базового программного продукта среди пяти поколений интегрированных систем
управления.
Чем больше номер поколения, тем проще установить, настроить и эксплуатировать систему , тем меньше
требуется личного участия фирмы-разработчика и/или ее партнеров в пусконаладочных работах и особенно
при эксплуатации. Например, компания Oracle специально подчеркивает возможность самостоятельного
развития приложений клиентом с помощью стандартных средств разработки Designer/2000 и Developer/2000.
Понятия «степень модульности» и «степень масштабируемости» также тесно связаны с поколением базового
продукта ERP системы . Так, например, средства взаимодействия с дополнительными модулями ALE и
XMA компаний SAP и Baan [3,5] , a также средства, обеспечивающие интерфейс с внешними системами
BAPI и BPC, были специально разработаны совсем недавно как отдельные продукты. В то же время средства
обмена сообщениями от IFS (MHS) или средства Открытого интерфейса Oracle изначально представляли
собой единый универсальный механизм синхронизации как собственных модулей, так и средств обмена
сообщениями с «чужими» модулями.
В качестве примера модульности и масштабируемости можно привести использование системы IFS на
мебельной фабрике, бизнес-процессы которой предусматривают ограниченный набор функций, охватываемых
«логистикой» (движение материалов, закупки, продажи, автоматические бухгалтерские проводки, баланcы,
отчеты), и около 40 терминалов, эксплуатацию системы поддерживают четыре работника АСУ, причем они
знают «только» стандартные средства DOS, SCO UNIX и Oracle. C другой стороны, система также
эксплуатируется на гиганте Volvo c разбросанными по всему миру заводами, где кроме «стандартного» набора
ERP модулей используется мощная подсистема Управления Ремонтами (Мaintenance), которую сегодня
начинают внедрять и на ММК. И в том, и в другом случае используется одно и то же программное
обеспечение, поддерживающее интеграцию управления, соответствующее уровню ERP .
На российских предприятиях имеет смысл более активно внедрять новые технологии - в них отсутствует
«давление груза» MRP систем 2-го поколения.
В дополнение к описанию эволюции ИСУ с точки зрения развития инструментальных средств [1] полезно
обсудить новые тенденции стандартизации, специализации и кооперации в ИСУ, которые уже выходят за
рамки систем 5-го поколения:
укрупняются типовые «общесистемные» функциональные блоки (Workflow, Web, DataWarehouse, EDI
и др.) [3], задействованные (например, Oracle) во всех «традиционных» ERP модулях ;
началась разработка единых стандартов организации взаимодействия между разными поставщиками
ERP систем (например, поддержка десятью ведущими производителями Единых Спецификаций Open
Application Group - OAGIS, http://www.oag.org);
началось расширение функциональности до cоответствия 3 и 4 уровням пятиуровневой модели
управления предприятием С.Бира [4], например, декларация Baan об MRP-III (Money Resource Planning),
предполагающая включение методологии Теории Ограничений (TOC) Голдрата (http://www.goldratt.com).
Критерий 2. Количество автоматизируемых бизнес-функций.
Очень часто этот критерий используется с некоторым мифологическим оттенком (больше - значит лучше).
Поэтому имеет смысл рассмотреть разные его аспекты более подробно.
С одной стороны, количество автоматизируемых бизнес-функций не может быть определяющим критерием
по следующим причинам:
25



большинство интегрированных систем , основанных на стандартах MRP/ ERP , имеют типовой
базовый набор автоматизируемых бизнес-функций [1];
основная задача рассийских менеджеров - почувствовать новую технологию интегрированного
управления - решается практически любой MRP системой (правда, за разную цену);
изучение всех бизнес-функций, предлагаемых ведущими зарубежными производителями (SAP, Oracle,
PeopleSoft, Baan), невозможно без освоения их базового набора и требует длительного времени (5 лет и
более).
Можно даже сказать, что богатство функций в сочетании с устаревшим инструментарием, «плохой»
логической структурой данных, отсутствием общепринятых «стандартных элементов» просто вредно для
неофитов от ИСУ. Так, внешнее богатство функций [6] эмоционально заслоняет реальную оценку
последствий использования собственных нестандартных средств поставщика.
С другой стороны, нужно как можно раньше начинать внедрять новые аналитические возможности таких
выделяемых в отдельные подсистемы функций, как работа с хранилищами данных, OLAP, системами
поддержки принятия решений (DSS) и аналитическими функциями более высокого уровня (например,
типовой модуль «Автоматическое предупреждение» Oracle (Alert).
Критерий 3. «МОНО» и «МУЛЬТИ» - ориентированность на поставщика СУБД .
Декларация независимости MRP/ ERP системы от конкретной СУБД - необходима прежде всего
разработчикам, а не клиентам, которые хотят внедрять систему [1]. Такая независимость во многом связана с
пережитками MRP систем 2-го поколения, когда разработчики использовали только свои собственные и
инструменты средства администрирования баз данных.
В общем процессе эволюции ИТ такие поставщики не смогут широко использовать возможности новых
поколений СУБД и современных средств разработки. Перейти к MRP/ ERP системам 4-го поколения для
поставщиков, ориентированных на несколько СУБД (имеющих свои собственные средства
администрирования и разработки), будет сложнее, чем для «МОНО» поставщиков [1]. Для «МУЛЬТИ»
поставщиков также будет сложно переключиться на объектно-ориентированную основу MRP/ ERP систем 5го поколения.
С точки зрения «провайдеров» ERP систем между МОНО и МУЛЬТИ имеется обратная зависимость. Так,
при ориентации на МУЛЬТИ будет более жесткой привязка к «хозяину», чем при ориентации на МОНО
поставщика, так как требуется освоить не только стандартные «коммерческие» средства разработки, но и
средства, специфичные для данного ERP провайдера.
Критерий 4. Легкость русификации системы при внедрении и сопровождении.
Этот критерий, требует отдавать предпочтение системам , имеющим средства табличного задания
переводимых понятий с автоматической перегенерацией экранных форм, меню и т.д. на другой язык. Даже
если ERP система уже локализована, нужно учитывать трудозатраты на развитие системы и адаптацию ее
новых версий.
Критерий 5. Опыт команды разработчиков/провайдеров в практическом внедрении «больших» систем
управления на предприятиях СНГ [2].
Наличие у команды методик адаптации идеологии MRP/ ERP к российским условиям часто оказывается
решающим фактором успешного внедрения - мало купить систему , надо еще и грамотно ее настроить, а
самое главное, довести до самостоятельного жизнеспособного существования, требующего минимальной
поддержки со стороны производителя.
Опыта многих российских компаний, специализирующихся на внедрении систем типа «Low End PC» и
«Middle PC» [3] для ERP систем оказывается недостаточно. Мы согласны с выводами, изложенными в
работе [3]. Действительно, новаторские российские разработки (с точки зрения функциональности) могут
быть сделаны «никак не в области финансово-экономических систем ». В лучшем случае нам всегда придется
догонять, а в худшем - будут появляться «пророки в своем отечестве» [8], которые станут выдавать свои
доморощенные поделки за откровения. Наш собственный опыт показывает, что сам факт практической
адаптации ERP-системы уже существенно повышает уровень понимания процессов управления на
предприятии. При этом преимущество имеют компании, использующие стандартный коммерческий
инструментарий 4-го поколения ИСУ, например Ост-ин [6] или Ай-Ти [7].
Критерий 6. Уровень компьютеризации предприятия на момент установки интегрированной системы
управления.
Чем более однородна вычислительная среда на предприятии и чем она ближе к поколениям 3 - 4
интегрированных систем (критерий 1), тем легче внедрить MRP систему (в металлургической отрасли СНГ
такой средой сегодня оказался Oracle [2]). И наоборот, когда эксплуатируются разнородные системы, внедрять
интегрированную систему очень сложно, если вообще возможно, без принципиальной переделки уже
26








эксплуатируемых систем (legacy systems). Причем независимо от того, продукт какой компании был выбран и
какие ресурсы она готова выделить на внедрение своего продукта.
Критерий 7. Гибкость ценовой политики фирмы-поставщика.
Учет этого критерия позволяет снизить прямые затраты на систему . Гибкость цен поставщика во многом
зависит от степени модульности системы и ее масштабируемости (см. критерий 1).
В целом мы рекомендуем - ориентироваться на типовые стандартные решения в широком смысле. Это
позволит, c одной стороны, без особого труда освоить современные технологии управления, а с другой выйти на новый уровень стандартизации и интеграции, к которому сегодня подошло мировое сообщество.
Можно привести несколько примеров нового уровня интеграции:
согласование стандартных спецификаций OAG для ERP систем с Manufacturing Domain Task Force
(MfgDTF) OMG;
использование Univesal Modelling Language (OMG) в новых объектно-ориентированных средствах
CASE (Rational Rose, Designer/2000);
активная работа подкомитета ISO TC184/SC4 по стандартизации «Архитектуры данных» любого
предприятия на основе объектноориентированных метамоделей в рамках сообщества STEP;
согласование стандартов CORBA, STEP, PDM.
Тезисы лекции №4. Характеристики MRP систем
Material Requirement Planning представляет собой комплексную систему планирования материальных
потребностей и производственных ресурсов предприятия, которая в настоящее время является одной из
наиболее распространенных логистических концепций.
История. Система MRP была создана в 50-х годах прошлого столетия в США, но активное распространение
получила только в 1970-е благодаря быстрому развитию вычислительной техники. Внедрение аналогичных
платформ проводилось и в СССР, но разработки преимущественно использовались в военно-промышленном
комплексе.
В конце 1980-х годов платформа MRP использовалась ведущими компаниями США с годовым объемом
реализации готовой продукции более 15 млн. долларов. В Великобритании данные системы были внедрены
более чем на 30% производственных предприятий.
Цели использования
Удовлетворение потребности клиентов в готовой продукции.
Поддержание требуемых объемов складских запасов.
Удовлетворение потребности производства в сырье, комплектующих и полуфабрикатах.
Планирование производственных, закупочных и складских операций, а также режима доставки.
Система MRP позволяет пользователям определять количество конечной продукции, которое требуется
произвести, а также сроки ее выпуска. Платформа рассчитывает объем материальных ресурсов, достаточный
для удовлетворения производственных потребностей в рамках утвержденного плана.
Развитие В процессе развития система была преобразована в методику планирования и учета корпоративных
ресурсов (MRP II, ERP). Основной задачей платформы являлось обеспечение предприятия требуемым
объемом сырья и материалов, а также учет и планирование производственных процессов и закупочных
операций. Хотя данные системы считались прорывом в области корпоративного управления, они имели ряд
существенных недостатков: сложность эксплуатации, отсутствие реагирования на кратковременные
изменения спроса и необходимость выполнения большого количества вычислений.
Характеристики систем MRP II
Методика представляет собой комплекс эффективных инструментов, позволяющих осуществлять
планирование как материальных, так и финансовых ресурсов предприятия. Данная система является одним из
наиболее действенных инструментов управления организацией, позволяющим обеспечить максимально
широкий охват требуемых ресурсов. MRP II учитывает весь спектр взаимосвязанных между собой процессов.
Функции платформы — планирование потребности в производственных мощностях, бизнес-планирование,
разработка календарного плана и т.д. Инструменты MRP II позволяют составлять план закупок и производства
в натуральном или денежном выражении, а также осуществлять моделирование, используя параметры
заданных условий.
Основы систем класса MRP-MRPII
Геннадий Верников, www.vernikov.ru
Философия и основные понятия MRP
В начале 60-х годов, в связи с ростом популярности вычислительных систем, возникла идея использовать их
возможности для планирования деятельности предприятия, в том числе для планирования производственных
процессов. Необходимость планирования обусловлена тем, что основная масса задержек в процессе
производства связана с запаздыванием поступления отдельных комплектующих, в результате чего, как
27
правило, параллельно с уменьшением эффективности производства, на складах возникает избыток
материалов, поступивших в срок или ранее намеченного срока. Кроме того, вследствие нарушения баланса
поставок комплектующих, возникают дополнительные осложнения с учетом и отслеживанием их состояния в
процессе производства, т.е. фактически невозможно было определить, например, к какой партии принадлежит
данный составляющий элемент в уже собранном готовом продукте. С целью предотвращения подобных
проблем, была разработана методология планирования потребности в материалах MRP (Material Requirements
Planning). Реализация системы, работающей по этой методологии представляет собой компьютерную
программу, позволяющую оптимально регулировать поставки комплектующих в производственный процесс,
контролируя запасы на складе и саму технологию производства. Главной задачей MRP является
обеспечивание гарантии наличия необходимого количества требуемых материалов-комплектующих в любой
момент времени в рамках срока планирования, наряду с возможным уменьшением постоянных запасов, а
следовательно разгрузкой склада. Прежде чем описывать саму структуру MRP, следует ввести краткий
глоссарий основных ее понятий:
 Материалами будем называть все сырье и отдельные комплектующие, составляющие конечный
продукт. В дальнейшем мы не будем делать различий между понятиями "материал" и
"комплектующий".
 MRP-система, MRP-программа -- компьютерная программа работающая по алгоритму,
регламентированному MRP методологией. Как и любая компьютерная программа, обрабатывает
файлы данных (входные элементы) и формирует на их основе файлы -результаты.
 Статус материала является основным указателем на текущее состояние материала. Каждый
отдельный материал, в каждый момент времени, имеет статус в рамках MRP-системы, который
определяет, имеется ли данный материал в наличии на складе, зарезервирован ли он для других целей,
присутствует ли в текущих заказах, или заказ на него только планируется. Таким образом, статус
материала однозначно описывает степень готовности каждого материала быть пущенным в
производственный процесс.
 Страховой запас материала необходим для поддержания процесса производства в случае
возникновения непредвиденных и неустранимых задержек в его поставках. По сути, в идеальном
случае, если механизм поставок полагать безупречным, MRP-методология не постулирует
обязательное наличие страхового запаса, и его объемы устанавливаются различными для каждого
конкретного случая, в зависимости от сложившейся ситуации с поступлением материалов. Подробней
об этом будет рассказано ниже.
 Потребность в материале в компьютерной MRP-программе представляет собой определенную
количественную единицу, отображающую возникшую в некоторой момент времени в течение периода
планирования необходимость в заказе данного материала. Различают понятия полной потребности в
материале, которая отображает то количество, которое требуется пустить в производство, и чистой
потребности, при вычислении которой учитывается наличие всех страховых и зарезервированных
запасов данного материала. Заказ в системе автоматически создается по возникновению отличной от
нуля чистой потребности.
Процесс планирования включает в себя функции автоматического создания проектов заказов на закупку и\или
внутреннее производство необходимых материалов-комплектующих. Другими словами система MRP
оптимизирует время поставки комплектующих, тем самым уменьшая затраты на производство и повышая его
эффективность. Основными преимуществами использования подобной системе в производстве являются:
 Гарантия наличия требуемых комплектующих и уменьшение временных задержек в их доставке, и,
следовательно, увеличение выпуска готовых изделий без увеличения числа рабочих мест и нагрузок на
производственное оборудование.
 Уменьшение производственного брака в процессе сборки готовой продукции возникающего из-за
использования неправильных комплектующих.
 Упорядовачивание производства, ввиду контроля статуса каждого материала, позволяющего
однозначно отслеживать весь его конвейерный путь, начиная от создания заказа на данный материал,
до его положения в уже собранном готовом изделии. Также благодаря этому достигается полная
достоверность и эффективность производственного учета.
Все эти преимущества фактически вытекают из самой философии MRP, базирующейся на том принципе, что
все материалы-комплектующие, составные части и блоки готового изделия должны поступать в производство
одновременно, в запланированное время, чтобы обеспечить создание конечного продукта без дополнительных
задержек. MRP-система ускоряет доставку тех материалов, которые в данный момент нужны в первую
очередь и задерживает преждевременные поступления, таким образом, что все комплектующие,
представляющие собой полный список составляющих конечного продукта поступают в производство
28
одновременно. Это необходимо во избежание той ситуации, когда задерживается поставка одного из
материалов, и производство вынуждено приостановиться даже при наличии всех остальных комплектующих
конечного продукта. Основная цель MRP-системы формировать, контролировать и при необходимости
изменять даты необходимого поступления заказов таким образом, чтобы все материалы, необходимые для
производства поступали одновременно. В следующем разделе будут детально рассмотрены входные элементы
MRP-программы и результаты ее работы. Формирование входной информации для MRP-программы и
результаты её работы На практике MRP-система представляет собой компьютерную программу, которая
логически может быть представлена при помощи следующей диаграммы:
Диаграмма 1 Входные элементы и результаты работы MRP-программы На приведенной выше
диаграмме отображены основные информационные элементы MRP-системы. Итак, опишем основные
входные элементы MRP-системы:
 Описание состояния материалов (Inventory Status File) является основным входным элементом
MRP-программы. В нем должна быть отражена максимально полная информация о всех материалахкомплектующих, необходимых для производства конечного продукта. В этом элементе должен быть
указан статус каждого материала, определяющий, имеется ли он на руках, на складе, в текущих
заказах или его заказ только планируется, а также описания, его запасов, расположения, цены,
возможных задержек поставок, реквизитов поставщиков. Информация по всем вышеперечисленным
позициям должна быть заложена отдельно по каждому материалу, участвующему в производственном
процессе.
 Программа производства (Master Production Schedule) представляет собой оптимизированный
график распределения времени для производства необходимой партии готовой продукции за
планируемый период или диапазон периодов. Сначала создается пробная программа производства,
впоследствии тестируемая на выполнимость дополнительно прогоном через CRP-систему (Capacity
Requirements Planning), которая определяет достаточно ли производственных мощностей для ее
осуществления. Если производственная программа признана выполнимой, то она автоматически
формируется в основную и становится входным элементом MRP-системы. Это необходимо потому как
рамки требований по производственным ресурсам являются прозрачными для MRP-системы, которая
формирует на основе производственной программы график возникновения потребностей в
материалах. Однако, в случае недоступности ряда материалов, или невозможности выполнить план
заказов, необходимый для поддержания реализуемой с точки зрения CPR производственной
программы, MRP-система в свою очередь указывает о необходимости внести в нее корректировки.
 Перечень составляющих конечного продукта (Bills of Material File) -- это список материалов и их
количество, требуемое для производства конечного продукта. Таким образом, каждый конечный
продукт имеет свой перечень составляющих. Кроме того, здесь содержится описание структуры
конечного продукта, т.е. он содержит в себе полную информацию по технологии его сборки.
Чрезвычайно важно поддерживать точность всех записей в этом элементе и соответственно
корректировать их всякий раз при внесении изменений в структуру и\или технологию производства
конечного продукта.
Напомним, что каждый из вышеуказанных входных элементов представляет собой компьютерный файл
данных, использующийся MRP-программой. В настоящий момент MRP-системы реализованы на самых
29
разнообразных аппаратных платформах и включены в качестве модулей в большинство финансовоэкономических систем. Мы не будем останавливаться на техническом аспекте вопроса и перейдем к описанию
логических шагов работы MRP-программы. Цикл ее работы состоит из следующих основных этапов:
1. Прежде всего MRP-система, анализируя принятую программу производства, определяет оптимальный
график производства на планируемый период.
2. Далее, материалы, не включенные в производственную программу, но присутствующие в текущих
заказах, включаются в планирование как отдельный пункт.
3. На этом шаге, на основе утвержденной программы производства и заказов на комплектующие, не
входящие в нее, для каждого отдельно взятого материала вычисляется полная потребность, в
соответствии
с
перечнем
составляющих
конечного
продукта.
4. Далее, на основе полной потребности, учитывая текущий статус материала, для каждого периода
времени и для каждого материала вычисляется чистая потребность, по указанной формуле. Если
чистая потребность в материале больше нуля, то системой автоматически создается заказ на материал.
5. И наконец, все заказы созданные ранее текущего периода планирования, рассматриваются, и в них,
при необходимости, вносятся изменения, чтобы предотвратить преждевременные поставки и задержки
поставок от поставщиков.
Таким образом, в результате работы MRP-программы производится ряд изменений в имеющихся заказах и ,
при необходимости, создаются новые, для обеспечения оптимальной динамики хода производственного
процесса. Эти изменения автоматически модифицируют Описание Состояния Материалов, так как создание,
отмена или модификация заказа, соответственно влияет на статус материала, к которому он относится. В
результате работы MRP-программы создается план заказов на каждый отдельный материал на весь срок
планирования, обеспечение выполнения которого необходимо для поддержки программы производства.
Основными результатами MRP-системы являются:
 План Заказов (Planned Order Schedule) определяет, какое количество каждого материала должно
быть заказано в каждый рассматриваемый период времени в течение срока планирования. План
заказов является руководством для дальнейшей работы с поставщиками и, в частности, определяет
производственную программу для внутреннего производства комплектующих, при наличии такового.
 Изменения к плану заказов (Changes in planned orders) являются модификациями к ранее
спланированным заказам. Ряд заказов могут быть отменены, изменены или задержаны, а также
перенесены на другой период.
Также, MRP-система формирует некоторые второстепенные результаты, в виде отчетов, целью которых
является обратить внимание на "узкие места" в течение планируемого периода, то есть те промежутки
времени, когда требуется дополнительный контроль за текущими заказами, а также для того чтобы вовремя
известить о возможных системных ошибках возникших при работе программы. Итак, MRP-система
формирует следующие дополнительные результаты-отчеты:
 Отчет об "узких местах" планирования (Exception report) предназначен для того, чтобы
заблаговременно проинформировать пользователя о промежутках времени в течение срока
планирования, которые требуют особого внимания, и в которые может возникнуть необходимость
внешнего управленческого вмешательства. Типичными примерами ситуаций, которые должны быть
отражены в этом отчете могут быть непредвиденно запоздавшие заказы на комплектующие, избытки
комплектующих на складах и т.п.
 Исполнительный отчет (Performance Report) является основным индикатором правильности работы
MRP-системы и имеет целью оповещать пользователя о возникших критических ситуациях в процессе
планирования, таких как, например, полное израсходование страховых запасов по отдельным
комплектующим, а также о всех возникающих системных ошибках в процессе работы MRPпрограммы.
 Отчет о прогнозах (Planning Report) представляет собой информацию, используемую для
составления прогнозов о возможном будущем изменении объемов и характеристик выпускаемой
продукции, полученную в результате анализа текущего хода производственного процесса и отчетах о
продажах. Также отчет о прогнозах может использоваться для долгосрочного планирования
потребностей в материалах.
Таким образом, использование MRP-системы для планирования производственных потребностей позволяет
оптимизировать время поступления каждого материала, тем самым значительно снижая складские издержки и
облегчая ведения производственного учета. Однако, среди пользователей MRP-программ существует
расхождение в мнениях относительно использования страхового запаса для каждого материала. Сторонники
30
использования страхового запаса утверждают, что он необходим в силу того, что зачастую механизм доставки
грузов не является достаточно надежным, и возникшее, в силу различных факторов, полное израсходование
запасов на какой-либо материал, автоматически приводящее к остановке производства, обходится гораздо
дороже, чем постоянно поддерживаемый его страховой запас. Противники использования страхового запаса
утверждают, что его отсутствие является одной из центральных особенностей концепции MRP, поскольку
MRP-система должна быть гибкой по отношению к внешним факторам, вовремя внося изменения к плану
заказов, в случае непредвиденных и неустранимых задержек поставок. Но в реальной ситуации, как правило,
вторая точка зрения может быть реализована для планирования потребностей для производства изделий,
спрос на которые относительно прогнозируем и контролируем и объем производства может быть установлен в
производственной программе постоянным в течение некоторого, относительно длительного периода. Следует
заметить, что в Российских условиях, когда задержки в процессах поставки являются скорее правилом, чем
исключением, на практике целесообразно применять планирование с учетом страхового запаса, объемы
которого устанавливаются в каждом отдельном случае.
Планирование производственных мощностей с помощью CRP-cистемы (Capacity Requirements
Planning) Система планирования производственных мощностей по методологии CRP применяется для
проверки пробной программы производства, созданной в соответствии с прогнозами спроса на продукцию, на
возможность ее осуществления имеющимися в наличии производственными мощностями. В процессе работы
CRP-системы разрабатывается план распределения производственных мощностей для обработки каждого
конкретного цикла производства в течение планируемого периода. Также устанавливается технологический
план последовательности производственных процедур и, в соответствии с пробной программой производства,
определяется степень загрузки каждой производственной единицы на срок планирования. Если после цикла
работы CRP-модуля программа производства признается реально осуществимой, то она автоматически
подтверждается и становится основной для MRP-системы. В противном случае в нее вносятся изменения, и
она подвергается повторному тестированию с помощью CRP-модуля. В дальнейшем эволюционном развитии
систем планирования производства они стали представлять собой интеграцию многих отдельных модулей,
которые, взаимодействуя, увеличивали гибкость системы в целом. В следующем разделе будут описаны
основные этапы дальнейшего развития систем класса MRP.
ЭВОЛЮЦИЯ MRP. ПЕРЕХОД ОТ MRP К MRPII
Системы планирования производства постоянно находятся в процессе эволюции. Первоначально MRPсистемы фактически просто формировали на основе утвержденной производственной программы план заказов
на определенный период, что не удовлетворяло вполне возрастающие потребности.
С целью увеличить эффективность планирования, в конце 70-х годов Оливер Уайт и Джордж Плосл
предложили идею воспроизведения замкнутого цикла (closed loop) в MRP-системах. Идея заключалась в
предложении ввести в рассмотрение более широкий спектр факторов при проведении планирования, путем
введения дополнительных функций. К базовым функциям планирования производственных мощностей и
планирования потребностей в материалах было предложено добавить ряд дополнительных, таких как
контроль соответствия количества произведенной продукции количеству использованных в процессе сборки
комплектующих, составление регулярных отчетов о задержках заказов, об объемах и динамике продаж
продукции, о поставщиках и т.д. Термин "замкнутый цикл" отражает основную особенность
модифицированной системы, заключающуюся в том, что созданные в процессе ее работы отчеты
анализируются и учитываются на дальнейших этапах планирования, изменяя, при необходимости программу
производства, а следовательно и план заказов. Другими словами, дополнительные функции осуществляют
обратную связь в системе, обеспечивающую гибкость планирования по отношению к внешним факторам,
таким как уровень спроса, состояние дел у поставщиков и т.п.
В дальнейшем, усовершенствование системы привело к трансформации системы MRP с замкнутым циклом в
расширенную модификацию, которую впоследствии назвали MRPII (Manufactory Resource Planning), ввиду
идентичности аббревиатур. Эта система была создана для эффективного планирования всех ресурсов
производственного предприятия, в том числе финансовых и кадровых. Кроме того, система класса MRRPII
способна адаптироваться к изменениям внешней ситуации и эмулировать ответ на вопрос "Что если". MRPII
представляет собой интеграцию большого количества отдельных модулей, таких как планирование бизнеспроцессов, планирование потребностей в материалах, планирование производственных мощностей,
планирование финансов, управление инвестициями и т.д. Результаты работы каждого из модуля
анализируются всей системой в целом, что собственно и обеспечивает ее гибкость по отношению к внешним
факторам. Именно это свойство является краеугольным камнем современных систем планирования,
поскольку большое количество производителей производят продукцию с заведомо коротким жизненным
циклом, требующую регулярных доработок. В таком случае появляется необходимость в автоматизированной
31
системе, которая позволяет оптимизировать объемы и характеристики выпускаемой продукции, анализируя
текущий спрос и положение на рынке в целом.
В последние годы системы планирования класса MRPII в интеграции с модулем финансового планирования
FRP (Finance Requirements Planning) получили название систем бизнес-планирования ERP (Enterprise
Requirements Planning), которые позволяют наиболее эффективно планировать всю коммерческую
деятельность современного предприятия, в том числе финансовые затраты на проекты обновления
оборудования и инвестиции в производство новой линейки изделий. В Российской практике,
целесообразность применения систем подобного класса обуславливается, кроме того, необходимостью
управлять бизнес процессами в условиях инфляции, а также жесткого налогового прессинга, поэтому,
системы ERP необходимы не только для крупных предприятий, но и для небольших фирм, ведущих активный
бизнес. На следующей диаграмме представлена логическая схема системы планирования ресурсов
производственного предприятия:
Диаграмма 2. Логическая структура системы планирования ресурсов производственного предприятия.
Предпосылки развития методик управления MRP II
Дмитрий Гаврилов, автор книги "Управление производством на основе стандарта MRP II", ведущий
консультант КГ "Воронов и Максимов" преподаватель СПбГПУ.
Последние десятилетия XX века были отмечены значительным усложнением промышленного
производства, расширением ассортимента производимой продукции, а также сокращением времени вывода
новых товаров на рынок.
Одновременно повысились требования потребителей к качеству продукции и уровню обслуживания, что
потребовало совершенствования методологии и технологии управления.
Возникла потребность, с одной стороны, в систематизации подходов к управлению производством, а с
другой стороны, в ускорении решения стоящих перед предприятием задач.
Возросшая сложность задач диктовала необходимость снять с человека рутинные расчетные функции,
задействовав потенциал вычислительной техники, и таким путем освободить время человека для
концентрации на принятии управленческих решений.
Таким образом можно выделить два актуальных аспекта: методологическое решение задач управления
и применение вычислительной техники для поддержки решения этих задач.
32
Говоря об основных преимуществах MRP-систем, нужно отметить такие результаты их внедрения как:
 улучшение обслуживания клиентов (иначе говоря, возросший уровень сервиса) - от 15 до 26 %
 снижение уровня запасов - от 16 до 30 %
 рост эффективности работы производственных подразделений - от 11 до 20 %
 снижение затрат на закупку - от 7 до 13 % (см. книгу Р.Гудфеллоу [3]).
Однако следует сказать, что, тем не менее, не весь мир MRP-зирован. Причиной этому является наличие
определенных характеристик производственной системы, при выполнении которых весьма вероятно
успешное внедрение MRP.
Желательными характеристиками для внедрения MRP, по мнению Н.Гайвера [2], являются следующие
свойства производственных систем:
1. эффективная компьютерная система;
2. точная информация о спецификациях продуктов (BOM'ах) и состоянии запасов на предприятии для
готовых продуктов и их компонент, материалов и сырья;
3. производственная система, ориентированная на производство дискретных продуктов, изготавливаемых из
сырья, деталей, узлов и сборочных единиц, проходящих в процессе своего изготовления через много
производственных операций;
4. производственные процессы с достаточно длительными циклами обработки;
5. относительно надежно устанавливаемые длительности производственных и закупочных циклов;
6. главный календарный план, фиксируемый на период времени, достаточный для заказа материалов без
излишней спешки и путаницы;
7. поддержка и участие верхних уровней управления предприятием (топ-менеджмента).
Отсутствие первых двух условий представляет большую проблему при реализации MRP на практике, и их
обеспечение требует весьма значительных затрат времени.
Д.Браун [1] среди главных причин неудач внедрения MRP - систем выделяет следующие четыре:
1. недостаточное участие в проекте высшего уровня менеджмента;
2. недостаточное обучение MRP тех, кто должен будет использовать систему;
3. нереалистичные главные календарные планы производства;
4. неточные данные, в особенности спецификации (BOM) и данные о складских запасах.
Активное участие в проекте внедрения системы высшего уровня менеджмента предприятия является
жизненно важным условием успеха внедрения MRP - системы. Надо понимать, что MRP - система
затрагивает очень многие сферы деятельности производственного предприятия, и без поддержки
должностных лиц, облеченных соответствующими полномочиями, ее реализация на практике будет
встречать сильное сопротивление.
Здесь можно сослаться на М.Сафизаде и Ф.Раафата [5], отметивших тот факт, что в производственной среде
существуют формальная и неформальная системы: "Во время внедрения MRP - системы хорошо
поставленная, в чем-то точная, неформальная система встречается с запросами и потребностями новой
формальной системы. Инсталляция MRP может улучшить функционирование производства или же вести
к сопротивлению и дезинтеграции".
Авторы пишут, что MRP очень требовательна к точности и своевременности данных и строгости
процедур управления производством и запасами.
Часто это становится основанием для изменения культуры работы для персонала, в особенности для
цехового персонала (начальников цехов, мастеров и др.), привыкшего с относительным успехом работать в
рамках неформальной системы с опорой на негласные приоритеты и с использованием списков
недостающих компонент и материалов (hot lists или shortage lists). Лэтем (Latham) отмечает, что "для многих
производственных предприятий MRP угрожает давно установившимся привычкам и прерогативам,
рожденным обстоятельствами и неформальными системами" [4].
Из вышесказанного можно заключить, что менеджмент должен принять на себя ответственность за
формирование производственной среды, необходимой для успешного внедрения MRP.
Однако следует отметить, что, возможно, имеет смысл допустить существование формальной и
неформальной систем вместе, но на достаточно короткое время, чтобы дать возможность персоналу
адаптироваться к новой формальной системе постепенно.