авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 || 3 | 4 |   ...   | 7 |

«Федеральное агентство по образованию Государственное образовательное учреждение высшего профессионального образования ...»

-- [ Страница 2 ] --

Многозначная зависимость не является функциональной, она существует в том случае, когда из факта, что в таблице содержится некоторая строка X, следует, что в таблице обязательно существует некоторая определённая строка Y. В четвертой нормальной форме отношение многие-ко многим между ПЕРСОНОЙ и ШКОЛОЙ разрешается за счет введения ассоциативной сущности, в которой отводится отдельная запись для каждой уникальной комбинации ШКОЛЫ и ПЕРСОНЫ.

Пятая нормальная форма (5NF) Таблица находится в 5NF, если она находится в 4NF и любая многозначная зависимость соединения в ней является тривиальной.

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

Copyright © 2010. Все права защищены. 43 Гущин А.Н.

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

Модели сущность-связь в объектном представлении Диаграмма классов.

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

Диаграмма объектов.

Объект представляет собой экземпляр класса - особую сущность, которая имеет заданные значения атрибутов и операций. Если на примере стиральной машины, то её атрибуты могут иметь вид: компания-производитель - "Сантехника", наименование модели - "Мойдодыр", серийный номер - "13-666-13" и ёмкость - фунтов.

Расширения языка:

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

Copyright © 2010. Все права защищены. 44 Гущин А.Н.

Ассоциации.

Если классы концептуально взаимодействуют друг с другом, то это взаимодействие называется ассоциацией. Ассоциации имеют ограничения(например {по очереди}, {или}), квалификатор(доп. информация в отношении "один ко многим"), классы, кратность, может быть рефлексивной. Может быть наследованием, зависимостью.

Copyright © 2010. Все права защищены. 45 Гущин А.Н.

Copyright © 2010. Все права защищены. 46 Гущин А.Н.

Агрегация, композитные объекты, интерфейсы и реализации.

Иногда класс состоит из некоторого количества классов компонентов. Это особый тип взаимосвязи, называемый агрегацией. Обозначается не закрашенным ромбом. Можно использовать {или} для того, чтобы показать выбор. Агрегация задаёт отношение "часть-целое".

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

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

· Открытая область "+" - все могут использовать.

· Защищённая область "#" - используется только наследниками.

· Закрытая область "-" - только класс имеет доступ.

· Реализация предполагает открытость операций интерфейса.

Copyright © 2010. Все права защищены. 47 Гущин А.Н.

Статические атрибуты и операции (присущие классу, единые для всех объектов данного класса) подчёркиваются.

Диаграммы потоков данных (DFD - Data Flow Diagramm) строятся из следующих элементов:

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

Хранилище Структура для хранения информационных объектов данных Внешняя Внешний по отношению к системе объект, обменивающийся с нею сущность потоками данных Такой тип обозначений элементов DFD-диаграммы получил название "нотация Йордона - Де Марко", по именам разработавших его специалистов.

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

· Функции преобразуют входящие потоки данных в выходящие · Хранилища данных не изменяют потоки данных, а служат только для хранения поступающих объектов · Преобразования потоков данных во внешних сущностях игнорируется Помимо этого, для каждого информационного потока и хранилища определяются связанные с ними элементы данных. Каждому элементу данных присваивается имя, также для него может быть указан тип даных и формат. Именно эта информация является исходной на следующем этапе проектирования - построении модели "сущность-связь". При этом, как правило, информационные хранилища преобразуются в сущности, проектировщику остается только решить вопрос с использованием элементов данных, не связанных с хранилищами.

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

Copyright © 2010. Все права защищены. 48 Гущин А.Н.

Эта диаграмма представляет самый верхний уровень функциональной модели.

Естественно, это весьма грубое описание предметной области. Уточнение модели производится путем детализации необходимых функций на DFD-диаграмме следующего уровня. Так мы можем разбить функцию "Определение потребностей и обеспечение материалами" на подфункции "Определение потребностей", "Поиск поставщиков", "Заключение и анализ договоров на поставку", "Контроль платежей", "Контроль поставок", связанные собственными потоками данных, которые будут представлены на отдельной диаграмме. Детализация модели должна производится до тех пор, пока она не будет содержать всю информацию, необходимую для построения информационной системы.

Физическая модель данных После создания полной и адекватной логической модели вы готовы к принятию решения о выборе платформы реализации. Выбор платформы зависит от требований к использованию данных и стратегических принципов формирования архитектуры Copyright © 2010. Все права защищены. 49 Гущин А.Н.

корпорации. Выбор платформы - сложная проблема, выходящая за рамки данного курса. В MS Visio физическая модель является графическим представлением реально реализованной базы данных. Физическая база данных будет состоять из таблиц, столбцов и связей. Физическая модель зависит от платформы, выбранной для реализации, и требований к использованию данных. Физическая модель для IMS будет серьезно отличаться от такой же модели для Sybase. Физическая модель для OLAP-отчетов будет выглядеть иначе, чем модель для OLTP (оперативной обработки транзакций).

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

Корпоративная модель данных (EDM - enterprise data model) содержит сущности, атрибуты и отношения, которые представляют информационные потребности корпорации. EDM обычно подразделяется в соответствие с предметными областями, которые представляют группы сущностей, относящихся к поддержке конкретных нужд бизнеса. Некоторые предметные области могут покрывать такие специфические бизнес-функции, как управление контрактами, другие - объединять сущности, описывающие продукты или услуги.

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

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

Корпоративные бизнес-объекты в рамках корпорации следует использовать единообразно.

Семинар: изучение возможностей MS Access.

Самостоятельная зачетная работа. Проектирование структуры базы данных (результат – модель в MS Visio).

Тема 4. Понятие корпоративной информационной системы Понятие корпоративной информационной системы Эволюция взглядов на корпоративную информационную систему. Классификация по типам, функциям, вариантам технической реализации.

Корпоративные системы MRP, MRPII, CSW.

Copyright © 2010. Все права защищены. 50 Гущин А.Н.

MRP (Material Requirement Planning) - планирование материальных потребностей.

Общая характеристика. Функции, выполняемые системой. Дальнейшее развитие.

Достоинства и недостатки ресурсного планирования.

MRP (Material Requirement Planning) Новая экономическая ситуация ставит перед предприятиями ряд задач, которые ранее ими не рассматривались. Среди наиболее важных задач, стоящих перед промышленными предприятиями в современных условиях, можно выделить:

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

В конкурентной борьбе побеждает только тот, кто быстрее других реагирует на изменения в бизнесе и принимает более верные решения. Именно информационные технологии помогают руководителям промышленных предприятий в решении этих сложных задач. Страны рыночной экономики имеют большой опыт создания и развития информационных технологий для промышленных предприятий. Одним из наиболее распространенных методов управления производством и дистрибуции в мире является стандарт MRP II (Manufacturing Resourse Planning), разработанный в США и поддерживаемый американским обществом по контролю за производством и запасами American Production and Inventory Control Society (APICS). APICS регулярно издает документ "MRP II Standart System", в котором описываются основные требования к информационным производственным системам. Последнее издание этой системы промышленных стандартов вышло в 1989 г.

MRP II - это набор проверенных на практике разумных принципов, моделей и процедур управления и контроля, служащих повышению показателей экономической деятельности предприятия. Идея MRP II опирается на несколько простых принципов, например, разделение спроса на зависимый и независимый. MRP II Standart System содержит описание 16 групп функций системы:

1. Sales and Operation Planning (Планирование продаж и производства).

2. Demand Management (Управление спросом).

3. Master Production Scheduling (Составление плана производства).

4. Material Requirement Planning (Планирование материальных потребностей).

5. Bill of Materials (Спецификации продуктов).

6. Inventory Transaction Subsystem (Управление складом).

7. Scheduled Receipts Subsystem (Плановые поставки).

8. Shop Flow Control (Управление на уровне производственного цеха).

9. Capacity Requirement Planning (Планирование производственных мощностей).

10. Input/output control (Контроль входа/выхода).

11. Purchasing (Материально техническое снабжение).

12. Distribution Resourse Planning (Планирование ресурсов распределения).

13. Tooling Planning and Control ( Планирование и контроль производственных операций).

Copyright © 2010. Все права защищены. 51 Гущин А.Н.

14. Financial Planning (Управление финансами).

15. Simulation (Моделирование).

16. Performance Measurement (Оценка результатов деятельности).

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

· 60-70 годах - планирование потребностей в материалах, на основании данных о запасах на складе и состава изделий, (Material Requierment Planning) · 70-80 годы - планирование потребностей в материалах по замкнутому циклу (Cloosed Loop Material Requirment Planning), включающее составление производственной программы и ее контроль на цеховом уровне, · конец 80-90-е - на основе данных, полученных от поставщиков и потребителей, ведение прогнозирования, планирования и контроля за производством, · 90-е - планирование потребностей в распределении и ресурсах на уровне предприятия – · Enterprise Resourse Planning и Distributed Requirements Planning.

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

Стандарт MRP II делит сферы отдельных функций (процедур) на два уровня:

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

Результаты использования интегрированных систем стандарта MRP II:

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

· долгосрочное, оперативное и детальное планирование деятельности предприятия с возможностью корректировки плановых данных на основе оперативной информации;

· решение задач оптимизации производственных и материальных потоков;

· реальное сокращение материальных ресурсов на складах;

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

· автоматизация работ договорного отдела с полным контролем за платежами, отгрузкой продукции и сроками выполнения договорных обязательств;

· финансовое отражение деятельности предприятия в целом;

Copyright © 2010. Все права защищены. 52 Гущин А.Н.

· значительное сокращение непроизводственных затрат;

· защита инвестиций, произведенных в информационные технологии;

· возможность поэтапного внедрения системы, с учетом инвестиционной политики конкретного предприятия.

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

Copyright © 2010. Все права защищены. 53 Гущин А.Н.

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

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

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

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

План объемов продаж и производства обычно включает следующие элементы:

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

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

Фокусом планирования объема продаж и производства является план производства. Хотя он и называется планом производства, это в принципе не просто Copyright © 2010. Все права защищены. 54 Гущин А.Н.

план выпуска продукции. Он требует наличие необходимого объема ресурсов по всей компании в целом. Если отдел маркетинга планирует скачек в продажах определенного ассортимента продуктов, инженеры должны обеспечить наличие необходимого объема оборудования;

отдел МТС должен будет обеспечить дополнительные поставки материалов (наличие новых поставщиков);

отдел кадров должен будет обеспечить наличие дополнительного объема трудовых ресурсов, а также организовать новые рабочие смены. Плюс ко всему необходимо будет обеспечить наличие необходимого объема капитала (для оплаты дополнительного объема ресурсов и запасов).

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

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

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

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

Copyright © 2010. Все права защищены. 55 Гущин А.Н.

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

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

автоматически, не требуют такой степени контроля (они зависят от ГПГП).

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

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

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

MRP отвечает на четыре основных вопроса:

· Что мы собираемся производить?

· Что нам для этого необходимо?

· Чем мы уже располагаем?

· Что нам необходимо дополучить?

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

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

ГПГП и данные о составе изделия позволяют системе определить Что, Сколько и Когда потребуется для того, чтобы произвести то, что нам нужно.

Copyright © 2010. Все права защищены. 56 Гущин А.Н.

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

CRP планирование потребностей в материалах Но наличие необходимого объема необходимых материалов ничего не значит без наличия достаточного свободного объема рабочего времени. CRP (или планирование потребностей в мощностях) - это планирование среднего уровня, которое использует данные запланированных MRP заказов и заказов на производство для определения необходимого объема рабочего времени (как по трудовым, так и по техническим ресурсам).

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

Каждая техоперация совершается на каком-то рабочем месте, которое может состоять из одного или нескольких человек и/или оборудования.

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

В цепи поставок может быть два и более уровней производственных и/или дистрибуторских подразделений. Эти подразделения могут находиться в различной зависимости друг от друга;

важным моментом является то, что одно подразделение может поставить продукцию другому подразделению. Например, компания Copyright © 2010. Все права защищены. 57 Гущин А.Н.

производит товары на территории одного подразделения, а продает их с отдельного склада продаж.

Другая компания может иметь центральный центр дистрибуции, который поставляет продукцию на склады региональных отделений.

И третий пример: компания имеет производственные мощности в двух городах.

Copyright © 2010. Все права защищены. 58 Гущин А.Н.

При планирование спроса и предложения материалов между подразделениями отвечают на три основных вопроса:

· Что нам нужно получить (с других подразделений)?

· Что мы собираемся поставить (другим подразделениям)?

· Что мы можем поставить?

Хотя эти вопросы и похожи на вопросы, задаваемые MRP (планирование потребностей в материалах), однако существует одно принципиальное отличие. В MRP достаточно знать Какой и Когда ожидается спрос и предложение. Когда же существует несколько подразделений, между которыми постоянно передвигается продукция, тогда DRP необходимо знать плюс ко всему где (каким подразделением) возник спрос/предложение.

Ответ на вопрос "Что нам нужно получить?" создает спрос на материалы, которые необходимо поставить с другого подразделения. DRP рассчитывает полностью все эти потребности (после запуска MRP).

На вопрос "Что мы собираемся поставить?" ответ возникает при оценке всех источников спроса на продукт, включая заказы клиентов, прогноз отгрузок, потребности в запчастях, страховой запас и межзаводской спрос. Используя данные по межзаводским запросам и заказам на распределение, между подразделениями ведется контроль спроса и предложения. На основе данных о потребностях подразделения на материалы, поставляемые другим подразделением, DRP создает запросы между этими подразделениями.

Ответ на последний вопрос "Что мы можем поставить" зависит от наличия материалов (предложение) и транспорта (ресурсов). Если спрос (потребности) превышает предложение, DRP можно использовать для закрепления материалов за несколькими подразделениями в указанной пропорции.

Концепция ERR-системы.

ERP (Enterprise Resource Planning System_ - система планирования ресурсов предприятия. Общая характеристика. Выполняемые функции Достоинства и недостатки. Проблемы внедрения и использования (чувствительность к ошибкам в данных, зависимость от корпоративной культуры).

Концепция ERP: планирование корпоративных ресурсов (Enterprise Resource Planning) Яркая черта современной экономики - интенсивные процессы интеграции участников рынка. Реструктуризация компаний, всплески слияний и поглощений, сращение промышленного и финансового капиталов, концентрация, специализация, диверсификация, кооперирование, интернационализация отражают эту тенденцию. В результате растет число корпораций (в том числе транснациональных), комплексов и объединений, холдингов, конгломератов, консорциумов, финансово-промышленных групп, стратегических альянсов. Развитие интернет-технологий, разработка платформ для электронного ведения бизнеса усугубят интеграционные процессы. По мнению многих экспертов, Интернет принесет бизнесу еще один способ интеграции виртуальную корпорацию, когда несколько компаний и/или частных лиц временно объединяются посредством современных коммуникационных средств для достижения общих целей.

Copyright © 2010. Все права защищены. 59 Гущин А.Н.

Интеграционные процессы вызвали существенные изменения во внутреннем устройстве компаний:

· усложнение организационной структуры:

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

· непростая система производственных и административных связей между этими автономными объектами;

· географическая разбросанность производственных, складских и/или сбытовых подразделений;

· сосуществование производств различных типов;

· диверсификация деятельности;

· наличие международной сети поставщиков комплектующих и услуг;

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

Главная цель концепции ERP - распространить принципы MRP II (Manufactory Resource Planning, планирование производственных ресурсов) на управление современными корпорациями.

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

Характеристические черты ERP-систем Системы класса ERP отличает набор следующих свойств:

· универсальность с точки зрения типов производств;

· поддержка многозвенного производственного планирования;

· более широкая (по сравнению с MRP II) сфера интегрированного планирования ресурсов;

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

· внедрение в систему средств поддержки принятия решений.

Возможность планирования производства всех типов в рамках одной системы Даже на обычном предприятии (не говоря уже о корпорации) могут сосуществовать производства различных типов ссылка. Например, у предприятия с основным производством непрерывного типа может быть вспомогательное производство, содержащее ремонтно-механические цеха, ориентированные на дискретный производственный цикл. Кроме того, предприятие может инициировать новое Copyright © 2010. Все права защищены. 60 Гущин А.Н.

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

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

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

Логика работы заложенных в ERP-системы средств агрегирования планов проста. Сначала формируются собственные планы закупок/поставок и производства для каждого предприятия-звена единой организационной структуры. При этом в план-графиках закупок и производства по каждой номенклатурной единице, входящей во внутрипроизводственную сеть поставок, указываются источник (потребитель) и приоритетность поставки этой единицы. Затем создается многозвенный (агрегированный) план. Для этого ERP-система обобщает потребности предприятий-звеньев в номенклатурных единицах, входящих в сеть внутренних поставок, и генерирует производственные планы для каждого звена с учетом поставок между звеньями. Прежде чем представить эти планы для утверждения, система проводит сценарную оценку их выполнимости. Как и в обычных MRP II системах, оценка выполнимости планов происходит путем создания системой потока заказов зависимого спроса на уровне всего производственного объединения. При выявлении критических состояний планы корректируются, и лишь затем поступают на утверждение.

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

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

В связи с этим, в ERP-системах появляются следующие дополнительные подсистемы.

Copyright © 2010. Все права защищены. 61 Гущин А.Н.

· Планирование и управление реализацией производственных проектов. В этой подсистеме ведется анализ проекта (разработка его структуры, выделение подпроектов, разбиение подпроектов на отдельные работы), формирование сетевых графиков работ, планирование материальных и трудовых ресурсов, оборудования, финансовых затрат для выполнения этих работ, управление ходом их выполнения.

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

· Планирование и управление распределенными ресурсами (Distribution Resources Planning). Такая подсистема предоставляет возможность работать со сложной многозвенной структурой сбытовых подразделений и складов. В частности, в ее компетенцию входит и планирование работы транспортных служб. С помощью подсистемы можно:

§ минимизировать транспортные затраты на доставку сырья и комплектующих;

§ организовать сбалансированное распределение материалов и продукции по складам компании;

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

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

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

Несмотря на довольно широкую функциональность, ERP-системы не являются полностью интегрированными системами управления: на многих предприятиях существуют подразделения, деятельность которых хотя и связана с производственным процессом, однако не укладывается в существующую идеологию MRP II- / ERP-систем. Для автоматизации работы таких подразделений используются свои системы. Речь идет, например, о системах автоматизированного проектирования (САПР), системах конструкторской и технологической подготовки производства (PDM-системы - Product Data Management). Поэтому реально ERP-системы (так же, Copyright © 2010. Все права защищены. 62 Гущин А.Н.

как и MRP II-системы) практически всегда используются совместно с подобными подсистемами.

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

Поэтому в ERP-системы входят мощные системы управления корпоративными финансами, характеризующиеся следующими особенностями:

· поддержка многозвенной структуры управления - возможность анализировать финансовые данные как на уровне отдельных подразделений-звеньев, так и на уровне всей компании;

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

· полнофункциональный аппарат ведения бухгалтерского и управленческого учета;

· ведение финансового планирования;

· ведение расчетов с дебиторами и кредиторами;

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

· полная интеграция с данными других подсистем ERP-систем.

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

· отслеживание эффективности работы различных участков и служб для выявления и устранения слабых звеньев, а также для совершенствования структуры бизнес процессов и организационных единиц;

· анализ деятельности отдельных подразделений;

· агрегирование данных из различных подразделений;

· анализ показателей различных направлений финансово-хозяйственной деятельности предприятия для выделения перспективных и убыточных направлений бизнеса;

· выявление тенденций, развивающихся как внутри предприятия, так и на рынке.

Различия между MRP II- и ERP-системами.

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

Copyright © 2010. Все права защищены. 63 Гущин А.Н.

Чуть выше были описаны характеристические черты ERP-систем. Они станут понятнее, если провести сравнительную характеристику систем двух классов - ERP и MRP II.

Сразу следует отметить, что и для MRP II-систем, и для ERP-систем основным является производство. Они, безусловно, развиваются в связи с запросами рынка:

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

ERP-системы создаются для больших многофункциональных и территориально распределенных производственных корпораций (например, холдингов, ТНК, ФПГ и т. д.). MRP II-системы ориентированы на рынок средних предприятий, которым не требуется вся мощность ERP-систем. Собственно, различие MRP II- и ERP-систем понятно уже из их названия: с одной стороны, планирование корпоративных ресурсов (Enterprise Resources Planning), с другой - планирование производственных ресурсов (Manufacture Resources Planning). Существенные же отличия ERP от MRP II можно выразить следующей формулой:

ERP = MRP II + реализация всех типов производства + интегрирование планирования ресурсов по различным направлениям деятельности компании + многозвенное планирование Безусловно, многие MRP II-системы развиваются с позиций глубины планирования и по некоторым параметрам приближаются к ERP-системам. Однако "по некоторым" не значит "по всем", поэтому с употреблением термина "ERP" нужно обращаться осторожно.

Современный рынок информационных управленческих систем состоит из тройки (по другим оценкам - пятерки) систем-лидеров, которые, собственно, и относятся к классу ERP, и множества "продвинутых" систем класса MRP II.

Безусловными лидерами являются системы SAP R/3 немецкой компании SAP AG, Oracle Applications американской компании Oracle и Baan, разработанная нидерландской компанией Baan (в мае 2000 года компания Baan была приобретена британским холдингом Invensys). Иногда к этому "элитному" списку добавляют OneWorld компании J.D.Edwards и PeopleSoft, выпускаемую одноименной компанией.

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

Поэтому "MRP II" - это не признак ущербности системы, а показатель того, что система ориентирована на рынок средних предприятий.

Концепция CRM-системы.

Copyright © 2010. Все права защищены. 64 Гущин А.Н.

CRM (Customer Relationship Management System) – система управления взаимодействием с клиентами (система управления продажами). Общая характеристика. Выполняемые функции. Достоинства и недостатки.

CRM-система - система управления взаимодействием с клиентами) — корпоративная информационная система, предназначенная для улучшения обслуживания клиентов путём сохранения информации о клиентах и истории взаимоотношений с клиентами, установления и улучшения бизнес-процедур на основе сохранённой информации и последующей оценки их эффективности. Её основные принципы таковы:

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

· синхронизированность управления множественными каналами взаимодействия (то есть существуют организационные процедуры, которые регламентируют использование этой системы и информации в каждом подразделении компании);

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

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

Классифицируют возможности (модули) CRM по функциональности и уровням обработки информации. По функциональности выделяют блоки:

· Продажи · Маркетинг · Сервисное обслуживание По уровням обработки информации:

· Оперативный — регистрация и оперативный доступ к первичной информации по Контактам, Компаниям, Проектам, Документам и т. д.

· Аналитический — отчетность по первичным данным и самое главное более глубокий анализ информации в различных разрезах (воронка продаж, анализ результатов маркетинговых мероприятий, анализ эффективности продаж в разрезе продуктов, сегментов клиентов, регионов и т. п.) · Коллаборационный (англ. collaboration - сотрудничество;

совместные, согласованные действия) — уровень организации тесного взаимодействия с конечными потребителями, клиентами, вплоть до влияния клиента на внутренние процессы компании (опросы, для изменения качеств продукта или порядка обслуживания, web-страницы для отслеживания клиентами состояния заказа, уведомление по SMS о проведённых транзакциях по банковскому счету, возможность для клиента самостоятельно скомплектовать и заказать в online к примеру автомобиль или компьютер из доступных блоков и опций и др.) Copyright © 2010. Все права защищены. 65 Гущин А.Н.

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

Тема 5. Анализ, проектирование, инжиниринг и реинжиниринг технологических процессов (бизнес-процессов) предприятия Анализ технологических процессов (бизнес-процессов) Всего на данный момент в мире насчитывается более 20 технологий организационного проектирования (помимо вышеназванных к ним относятся DFD, ABC, Flow Chart, Gannt, Workflow, etc.). Наиболее распространёнными в настоящее время методологиями функционального моделирования бизнес-процессов являются стандарты семейства IDEF и методологии ARIS и UML. Об их особенностях, положительных и отрицательных сторонах написано немало книг и отдельных статей. Их всегда можно найти в книжных магазинах и интернете.


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

Основные его отличительные характеристики это простота и строгость. И интуитивно понятные большинству сотрудников изобразительные средства, которым они обучаются, как правило, с удивительной лёгкостью. При всём при этом данный стандарт, основанный на методологии SADT (методологии структурного анализа и проектирования), имеет ряд других важнейших преимуществ. Например, очень высокую степень распространённости во всём мире в проектах, связанных с описанием, разработкой и изменением бизнес-процессов. Строгое использование формата бумаги А4 для формирования диаграмм и ограничение числа объектов на диаграмме восемью (а рекомендовано — не более 5-6) функциональными блоками — это позволяет эффективно работать с моделью процессов даже самых широких предметных областей в обычных условиях обычного офиса, а не вынуждает для её обсуждения или анализа «расстилать простыни» по столам конференц-зала или «развешивать» их на стене. Несколько лет назад на основе методологии SADT Госстандартом России были разработаны и утверждёны «Рекомендации по стандартизации «Методология функционального моделирования» — ГОСТ Р 50.1.028-2001, фактически повторяющие стандарт IDEF0.

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

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

В последовательности выработки требований заказчика по этапу системного анализа и проектирования выделяют три фазы:

Copyright © 2010. Все права защищены. 66 Гущин А.Н.

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

· обобщение результатов системного анализа и создание предварительной концепции новой или модернизированной информационной системы;

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

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

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

· получить снимок бизнес - и информационных процессов, сложившихся в организации;

· выявить узкие места в бизнес-процессах и наметить пути их ликвидации;

· создать информационную и функциональную модель новой системы;

· сформировать список требований к новой или модернизированной информационной системе;

· выбрать методы и средства проектирования и реализации информационной системы;

· сформировать архитектуру системы;

· сформировать состав программных компонент, которые необходимо приобрести в рамках создания информационной системы;

· составить предварительный укрупненный план проектирования и реализации базовой версии информационной системы;

· оценить трудозатраты разработки новой информационной системы;

· составить технико-экономическое обоснование.

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

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

· наличие совокупности тесно взаимодействующих компонентов (подсистем), имеющих свои локальные задачи и цели функционирования, например, Copyright © 2010. Все права защищены. 67 Гущин А.Н.

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

· необходимость интеграции существующих и вновь разрабатываемых приложений;

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

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

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

Обязательным свойством КИС является ее системность, то есть понимание КИС как объекта, имеющего новое системное свойство, которым не обладают отдельные компоненты.

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

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

· основные бизнес-процессы (бизнес-процессы, которые дают результат для клиента);

Copyright © 2010. Все права защищены. 68 Гущин А.Н.

· вспомогательные бизнес-процессы (бизнес-процессы, дающие результат для основного бизнес-процесса или организации).

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

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

Существует большое количество систем для их автоматизации - от небольших узконаправленных систем (1С-бухгалтерия, БОСС-Кадровик и др.), до комплексных систем класса ERP (SAP/R3, Oracle Applications и др.).

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

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

Методы и средства проектирования КИС При проектировании программного обеспечения используется несколько методов.

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

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

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

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


В структурном анализе используются такие методики, как:

· DFD (Data Flow Diagrams) - диаграммы потоков данных;

· IDEF0 (Icam DEFinition) - функциональные диаграммы.

Copyright © 2010. Все права защищены. 69 Гущин А.Н.

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

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

Применение методов и средств проектирования КИС Поскольку в построении модели предметной области кроме аналитиков на начальной стадии принимают участие эксперты предметной области (рис. 5), к применяемым моделям выдвигаются следующие требования:

· описание бизнес-процессов должно быть простым и понятным экспертам предметной области, которые не имеют специальной подготовки аналитиков;

· описание бизнес-процессов должно легко читаться и не быть при этом громоздким и сложным для корректировки;

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

В настоящее время экспертам предметной области наиболее доступны к пониманию структурные модели бизнес-процессов. Однако, наиболее понятным, несомненно, Copyright © 2010. Все права защищены. 70 Гущин А.Н.

является текстовое описание, которое также позволяет вносить корректуру в описание бизнес-процессов самим экспертам предметной области.

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

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

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

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

В 1998 году была издана монография А. Кобурна "Эффективное написание прецедентов". Реакция аудитории на нее была строго положительной и до сих пор в рейтингах электронных книжных магазинов эта работа получает отличные оценки.

Причина успеха объясняется тем, что была предложена строгая и логичная система Copyright © 2010. Все права защищены. 71 Гущин А.Н.

применения прецедентов;

сформулировано новое определение прецедента, предложена структура его текстового описания (спецификации). "Прецедент определяет соглашение между заинтересованными лицами (stakeholder) относительно поведения системы. Прецедент описывает поведение системы в ответ на запрос со стороны одной из зантересованных сторон, который называется основным (primary) актером. Основой актер инициирует запрос для осуществления некоторой цели;

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

Прецедент объединяет все такие сценарии. Причем, написанный по структуре А.

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

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

Необходимо обратить внимание на ключевую мысль, которая лейтмотивом проходит через всю книгу: "Написание преценьлв фундаментально означает написание этюдов в прозе (в оригинале essays in prose) со всеми трудностями, которые присущи написанию хороших текстов в общем случае". Диаграммы прецедентов языка UML при этом могут использоваться в качестве:

· оглавления для прецедентов;

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

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

Подходы к проектированию технологических процессов (бизнес-процессов).

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

Принципы проектированию (организации) технологических процессов 1) Общие принципы реорганизации бизнес-процессов, a) Поиск лучших отраслевых решений (best practices) и разработка нескольких альтернативных моделей процессов, b) Вертикальное и горизонтальное «сжатие» процесса, c) Нелинейный, итерационный процесс, d) Ориентация на выходные продукты — конечный результат бизнес-процесса, e) «Поручите выполнение процесса тем, кто использует его результат», f) «Включайте обработку информации в реальную работу, которая генерирует эту информацию», g) «Связывайте параллельные работы вместо интеграции их результатов», Copyright © 2010. Все права защищены. 72 Гущин А.Н.

h) «Помещайте точку принятия решения туда, где делается работа, и встраивайте контроль в процесс», i) «Фиксируйте информацию один раз — у источника».

2) Технические принципы реорганизации бизнес-процессов, a) Соответствие привлеченных ресурсов задачам, b) Соответствие физических и логических входов/выходов процесса, c) Отражение возможных ошибок и проблем, d) Устранение «разрывов» на функциональных стыках, e) Поиск и исключение неиспользуемых выходов процесса, f) Координация работ, g) Устранение дублирования функций, h) Контрольные точки.

Поиск лучших отраслевых решений (best practices) и разработка нескольких альтернативных моделей процессов.

Подходы к реорганизации бизнес-процессов должны базироваться на анализе опыта передовых предприятий и разработке альтернативных вариантов моделей процесса.

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

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

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

3 Использование Источником таких моделей могут служить:

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

2. референтные модели консалтинговых фирм;

3. различные стандарты.

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

Разработка и последующий анализ альтернативных вариантов Copyright © 2010. Все права защищены. 73 Гущин А.Н.

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

Последовательность действий «бизнес-процесс».

Модель «как есть».

Вариант 1 модели «как должно быть». Из процесса исключается процедура 2.

Copyright © 2010. Все права защищены. 74 Гущин А.Н.

Вариант 2 модели «как должно быть». Процедуры 3 и 5 заменяются одной процедурой 7.

Сравнение моделей при помощи анализа критериев эффективности.

Вертикальное и горизонтальное «сжатие» процесса.

Вертикальное «сжатие» бизнес-процесса — сокращение уровней функциональной иерархии, задействованных в выполнении процедур процесса и принятии решений.

Пример вертикального «сжатия» процесса приводится на следующих рисунках.

Представленная на рисунке модель «как есть» бизнес-процесса включает несколько итерационных согласований, в которых принимают участие Экономист, Начальник Отдела и Начальник Управления. Таким образом, для выполнения процесса необходимо участие сотрудников трех уровней функциональной иерархии.

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

Copyright © 2010. Все права защищены. 75 Гущин А.Н.

Модели «как есть»

и «как будет»

Copyright © 2010. Все права защищены. 76 Гущин А.Н.

На рисунке «как должно быть» представлена модель, в которой устранены итерационные согласования, например за счет делегирования полномочий по принятию решений Экономисту Отдела. Начальник Отдела лишь просматривает и визирует документацию в конце процесса (процедура 9), после чего информации передается Начальнику Управления.

Горизонтальное «сжатие»

бизнес-процесса — устранение неэффективных процедур процесса, итерационных согласований на одном уровне иерархии, сокращение времени выполнения процедур процесса, времени простоя и т.д.

Пример горизонтального «сжатия» процесса приводится на рисунке.

Модель процесса «как должно быть».

Сокращение времени выполнения функций.

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

реинжиниринга — Хаммера и Чампи.

Первый подразумевает рутинную, кропотливую работу по детальному анализу бизнес-процессов и разработке мер по их реорганизации.

Copyright © 2010. Все права защищены. 77 Гущин А.Н.

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

Нелинейный, итерационный процесс.

Инженерия (организация) бизнес процессов не является линейным, последовательно выполняемым и легко планируемым процессом.

Надо быть готовым к тому, что придется несколько раз возвращаться к началу этапа, т.е.

к разработке нескольких вариантов моделей «как должно быть». Необходимо выполнить несколько итераций, прежде чем будет получено приемлемое решение, существенно увеличивающее эффективность бизнес-процесса. Итерационный характер разработки моделей следует учитывать при планировании работ по проекту.

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

Copyright © 2010. Все права защищены. 78 Гущин А.Н.

Принцип ориентации на результат Ориентация на выходные продукты — конечный результат бизнес-процесса.

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

«…организовывайте достижение результата, а не выполнение задачи…».

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

Copyright © 2010. Все права защищены. 79 Гущин А.Н.

Инжиниринг технологических процессов (бизнес-процессов).

Понятие инжиниринга бизнес-процессов. Формы инжиниринга: CPI (непрерывное усовершенствование) с небольших (пробных) изменений до полной модификации системы и BPR (точечное усовершенствование бизнес-процессов) программа с фокусом на конкретных бизнес-процессах;

Оценка эффективности бизнес-процесса При оценке эффективности бизнес-процесса могут рассматриваться две группы показателей:

· типовые показатели;

· специальные показатели.

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

· показатели выполнения;

· показатели стоимости;

· показатели эффективности;

· показатели качества;

· показатели наблюдаемости;

· показатели управляемости.

Показатели выполнения В качестве показателей выполнения могут использоваться следующие параметры:

время выполнения процесса в целом (в человеко-днях);

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

· количество автоматизированных функций процесса;

· количество полностью или частично дублирующих друг друга функций:

· в рамках процесса;

· для остальных процессов;

· количество функций, контролирующих выполнение процесса.

Показатели стоимости К показателям стоимости можно отнести такие параметры бизнес-процесса, как:

· суммарная стоимость процесса, рассчитанная по методике АВС;

· стоимость поддержания процесса в рабочем состоянии (стоимость владения процессом);

· стоимость производимых процессом выходных материальных продуктов (услуг, информации).

Показатели эффективности Показатели эффективности бизнес-процесса могут определяться следующим образом:

Copyright © 2010. Все права защищены. 80 Гущин А.Н.

Числитель показатель процесса Знаменатель целевое стоимостные показатель аналогичный значение характеристики выполнения показатель показателя процесса референтного процесса Примеры показателей эффективности:

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

· рентабельность процесса;

· степень автоматизации по количеству функций (количество функций с возможностью автоматизации / общее количество функций процесса);

· степень автоматизации по времени (суммарное время автоматизированных работ / суммарное время выполнения всех работ) · отношение суммарного времени выполнения функций процесса к суммарному времени ожидания;

· отношение суммарного времени выполнения функций-интерфейсов взаимодействия с другими процессами к суммарному времени ожидания.

Показатели качества Показатели качества бизнес-процесса могут определяться на основе требований стандартов, например серии ISO-9000 и/или внутренней общей системы управления качеством (TQM). Основой для формирования показателей качества может служить степень удовлетворенности клиента процесса. Клиентами процесса могут являться как внешние потребители продуктов и услуг предприятия, так и подразделения предприятия, использующие результаты выполнения процесса — т.н. «внутренние клиенты».

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

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

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

Copyright © 2010. Все права защищены. 81 Гущин А.Н.

Рисунок 10а.

Рисунок 10б.

Реинжиниринг технологических процессов (бизнес-процессов).

Понятие реинжиниринга. Когда стоит применять. Выбор цели. Выбор критерия.

Препятствия для проведения. Основные приемы реинжиниринга.

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

Принцип «Поручите выполнение процесса тем, кто использует его результат».



Pages:     | 1 || 3 | 4 |   ...   | 7 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.