Сравнение отечественных и западных систем управления предприятием

Приведен сравнительный анализ отечественных систем класса управления предприятием с зарубежными системами класса MRPII/ERP. В качестве базового принят функциональный состав ERP-систем. Основные отличия между зарубежными и российскими системами заключаются в следующем:

1.Зарубежные системы ориентированы на хорошо структурированную иерархическую систему процессов, выполняемых на предприятии.

2. Зарубежные системы, как правило, опираются на наборы стандартов, которым процессы должны удовлетворять, например стандарт MM AS.

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

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

5.Российские системы, как правило, направлены на решение только задач учета и генерации бухгалтерской отчетности (см. Табл.1).

Таблица 1

Сравнение отечественных и зарубежных информационных систем

	Отечественная система				Зарубежная система
Функция системы	Позволяет делать			Качественный выигрыш	Позволяет делать	Качественный выигрыш
Блок проектирования
Item Part Number Control (Управление структурой изделия)	нет			нет	Управляет структурой изделия с точностью до комплектующих (узлов и агрегатов)	Повышение точности данных для планирования производственной деятельности, обеспечение стыка с системами проектирования
Bill of Materials Control (Управление спецификациями продуктов)	нет			нет	Контролирует весь перечень материалов, требуемых для производства конечного изделия (как количественно, так и в финансовом эквиваленте)	Повышение точности данных для планирования производственной деятельности, обеспечение стыка с системами проектирования
Блок контроля инженерной документации
Routings (Маршрутизация)	нет			нет	Управляет распределением потока заказов по цехам (рабочим местам)	Оптимальная загрузка цехов(оборудования)
Estimating (Смета)	нет			нет	Оценка влияния изменений	Точный учет затрат, связанных с изменениями
Design Engineering (Разработка технологии)	нет			нет	Подготав л ивает технологию выпуска продукции	Оптимальная технология выпуска продукции
Блок управления закупками
Vendor Performance (Исполненные поставки)	Учет поступлений на склад			Точный учет запасов	Учет исполнения запланированных поступлений	Точный учет запасов, повышение достоверности планирования
Purchase Order Management (Управление заказами на закупку)	нет			нет	Планирование и ввод заказов на закупку	Сокращение материальных запасов за счет обеспечения поставок в требуемый срок
Subcontract Purchase Orders (Заказы на закупку по субконтрактам)		нет		нет	Планирование и ввод заказов на закупку, выполняемых субподрядчиками	Сокращение материальных запасов за счет обеспечения поставок в требуемый срок
Блок управления материальными запасами
Inventory Control (Управление запасами)		Учет запасов		Точный учет запасов	Планирование и учет запасов	Сокращение материальных запасов за счет планирования поставок к требуемому сроку
Master Production Scheduling (План-график выпуска продукции)		нет		нет	Среднесрочный объемно-календарный план выпуска продукции	Выпуск продукции к требуемому сроку, сокращение издержек на хранение продукции
Material Requirements Planning (Планирование потребностей в материалах)		нет		нет	Планирование необходимых материалов по количеству и срокам	Сокращение времени простоя из-за нехватки материалов, сокращение материальных запасов
Lot/Serial Tracking (Отслеживание партий/серий)		Партионный учет на складе		Поддержка процессов ценообразования, учета издержек, продаж	Учет выпуска партий продукции	Повышение точности планирования продаж, сокращение материальных запасов
Rough-Cut Capacity Planning (Укрупненное планирование мощностей)		нет		нет	Планирование необходимых мощностей на основании требуемых для выпуска видов продукции ресурсов	Оптимальная загрузка критических ресурсов под виды продукции
Производственный блок
Shop Floor Control (Управление на уровне производственного цеха)		нет		нет	Составление оперативных (дни-месяц) план-графиков	Оптимальная загрузка цеха, детальное планирование выпуска продукции
Capacity Requirements Planning (Планирование потребностей в мощностях)		нет		нет	Детальное планирование потребных мощностей до уровня рабочих центров	Оптимальная загрузка всех рабочих мест
Project Control (Управление проектом)		нет		нет	Управление проектами предприятия	Выполнение проектов с требуемым качеством в заданные сроки
Блок управления издержками
Job Costing (Трудовые издержки)		Учет кадров, расчет заработной платы		Вся российская специфика кадрового учета и расчета заработной платы	Рассчитывает трудозатраты	Выделение затрат, связанных с работой персонала
Cash Flow Analysis (Анализ наличных потоков)		Как правило, наличные денежные потоки учитываются разными функциями		Учет наличных поступлений и выплат	Анализ всех денежных потоков предприятия	Оптимальное регулирование денежных потоков
Actual Costs (Действительные издержки)		нет		нет	Расчет реальной себестоимости	Выявление неэффективных участков и технологий
Standard Costs (Нормативная стоимость)			Разнесение издержек в рамках бухгалтерского плана счетов	Оптимизация налогообложения	Расчет плановой себестоимости	Поддержка процесса снижения издержек
Work Breakdown Structure (Стоимость этапов работ)			нет	нет	Расчет себестоимости работ по отдельным этапам	Поддержка процесса снижения издержек
Блок управления финансами
Accounts Receivable (Выставленные счета)			Выставление счетов к оплате	Учет выставленных счетов	Выставление счетов к оплате	Учет выставленных счетов
Accounts Payable (Оплаченные счета)			Регистрация оплаты счетов	Учет реальной оплаты выставленных счетов	Регистрация оплаты счетов	Учет реальной оплаты выставленных счетов
General Ledger (Главная книга)			Учет всех бухгалтерских операций	Реальная картина текущего баланса	Учет всех бухгалтерских операций	Реальная картина текущего баланса
Multi-Company Consolidation (Консолидация баланса от многих компаний)			Объединение баланса нескольких дочерних компаний	Реальная картина баланса нескольких компаний. Как правило, только на конец отчетного периода	Объединение баланса нескольких дочерних компаний	Реальная картина баланса нескольких компаний.
Foreign Currency Conversion (Конвертор валют)			Работа с несколькими валютами	Возможность осуществления расчетов в нескольких валютах	Работа с несколькими валютами	Возможность осуществления расчетов в нескольких валютах
Блок маркетинга/продаж
Sales Order Management (Управление заказами на продажу)			нет	нет	Учет заказов на продукцию	Оптимальная загрузка производства
Order Configurator (Конфигурация заказов)			Ведение книги продаж/покупок	Соответствие законодательству, сокращение затрат	Ведение книги продаж/покупок	Соответствие законодательству, сокращение затрат
Billing/Invoicing (Выставление счетов-фактур)			нет (есть только на уровне бухгалтерских счетов)	нет	Анализ всех аспектов продаж	Повышение достоверности прогнозирования/ планирования
Full Sales Analysis (Полный анализ продаж)			нет	нет	Расчет скидок/комиссионных	Гибкая работа с поставщиками и потребителями
Sales Forecasting/Rollups (Прогнозирование продаж)			нет	нет	Подготовка исходных данных для производственных планов верхнего уровня	Повышение достоверности планирования
Quoting (Квотирование) S			нет	нет	Квотирование продаж	Повышение прибыли за счет управления спросом

Вопросы для самоконтроля

1. Какие типы предприятий существуют?

2. На какие классы разбивают информационные системы?

3. Какие виды информационных систем поддерживают производственный цикл?

4. В отличие российских и зарубежных информационных систем?

5. Какие позитивные стороны существуют при внедрении информационных систем различных классов?

6. Какие возможности открываются при использовании ERP систем?

7. Какие можно отметить особенности при внедрении ERP систем?

Семинарское занятие по теме «Преимущества и недостатки закупки готовых или разработки новых ИС»

Заказные и уникальные системы. Тиражируемые системы. Проблема адаптации и адаптируемые системы. Общие рекомендации по выбору информационных систем: общие свойства, функциональные возможности, особые требования.

Все автоматизированные системы управления предприятием (АСУП) можно разделить на две большие группы:

• Заказные (уникальные системы)

• Адаптируемые системы

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

Хотя многие компании, предлагающие ERP-системы, и утверждают, что стоимость их внедрения в России равна или даже меньше стоимости лицензий на систему, реально дело обстоит несколько сложнее:

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

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

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

Основой адаптируемой ERP - системы является базовая система, которая включает в себя пакеты прикладных программ для решения задач управления, средства комплексирования задач в требуемые конфигурации, средства сопряжения с другими системами, например, с САПР и многое другое. Базовая система позволяет создавать для предприятия гибкую модифицируемую автоматизируемую систему управления предприятием, в которой сочетаются типовые подходы к решению задачу правления и специфические особенности предприятия. Базовые системы обычно ориентированы на определенный класс предприятий и функциональную структуру автоматизируемую систему управления предприятием. Эти отличия накладывают серьезный отпечаток на выбор базовой системы и на процесс создания автоматизируемую систему управления предприятием.

Вопросы для самоконтроля

1. Какие информационные системы называют заказными?

2. Что означает адаптация?

3. Когда информационную систему называют уникальной?

4. В чем проявляются различия тиражируемой и адаптируемой информационной системы?

5. Какие существуют способы приобретения ИС?

6. Что означает аутсорсинг?

7. Какие имеются преимущества и недостатки у заказных и уникальных информационных систем?

Семинарское занятие по теме «Управление ИС на различных этапах жизненного цикла ИС»

Планирование ИС; анализ требований к ИС; проектирование, программирование, тестирование и отладка ИС; эксплуатация и сопровождение. Внедрение ИС. Существующие модели жизненного цикла: каскадная, поэтапная, спиральная.

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

1. уровень научно-технического развития в организации, т.е. насколько современны используемые технологии ;

2. люди и существующая в организации культура.

Методология проектирования информационных систем описывает процесс создания и сопровождения систем в виде жизненного цикла (ЖЦ) информационной системы, представляя его как некоторую последовательность стадий и выполняемых на них процессов. Для каждого этапа определяются состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д. Такое формальное описание жизненного цикла информационной системы позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом.

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

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

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

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

Рис. 4.  Каскадная модель ЖЦ Рис. 5.  Поэтапная модель с промежуточным контролем

Рис. 6.  Спиральная модель ЖЦ ИС

На практике наибольшее распространение получили две основные модели жизненного цикла:

каскадная модель (характерна для периода 1970-1985 гг.);

спиральная модель (характерна для периода после 1986.г.).

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

Можно выделить следующие положительные стороны применения каскадного подхода:

• на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;

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

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

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

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

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

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

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

Иллюзия снижения рисков участников проекта (заказчика и исполнителя). Каскадная модель предполагает разработку законченных продуктов на каждом этапе: технического задания, технического проекта, программного продукта и пользовательской документации. Разработанная документация позволяет не только определить требования к продукту следующего этапа, но и определить обязанности сторон, объем работ и сроки, при этом окончательная оценка сроков и стоимости проекта производится на начальных этапах, после завершения обследования. Очевидно, что если требования к информационной системе меняются в ходе реализации проекта, а качество документов оказывается невысоким (требования неполны и/или противоречивы), то в действительности использование каскадной модели создает лишь иллюзию определенности и на деле увеличивает риски, уменьшая лишь ответственность участников проекта. При формальном подходе менеджер проекта реализует только те требования, которые содержатся в спецификации, опирается на документ, а не на реальные потребности бизнеса. Есть два основных типа контрактов на разработку программного обеспечения. Первый тип предполагает выполнение определенного объема работ за определенную сумму в определенные сроки (fixed price). Второй тип предполагает повременную оплату работы (time work). Выбор того или иного типа контракта зависит от степени определенности задачи. Каскадная модель с определенными этапами и их результатами лучше приспособлена для заключения контракта с оплатой по результатам работы, а именно этот тип контрактов позволяет получить полную оценку стоимости проекта до его завершения. Более вероятно заключение контракта с повременной оплатой на небольшую систему, с относительно небольшим весом в структуре затрат предприятия. Разработка и внедрение интегрированной информационной системы требует существенных финансовых затрат, поэтому используются контракты с фиксированной ценой, и, следовательно, каскадная модель разработки и внедрения. Спиральная модель чаще применяется при разработке информационной системы силами собственного отдела IT- предприятия.

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

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

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

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

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

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

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

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