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

Хотя рассмотренные в двух предыдущих разделах подсистемы МТР и SCCP обеспечивают весьма мощный механизм передачи, включая возможность динамической маршрутизации, они не могут интерпретировать значения передаваемых сообщений уровня 4. Определяет значение передаваемых сообщений и назначает порядок их передачи, а также взаимодействует с программным обеспечением обслуживания вызовов на станции одна из подсистем пользователя. Для управления установлением соединения и освобождением разговорного тракта, в частности, специфицированы несколько подсистем пользователя ОКС7, в частности, подсистема пользователя телефонной связи (TUP), подсистема пользователя ISDN (ISUP).

Подсистема телефонного пользователя TUP была разработана для управления установлением и разъединением телефонных соединений и являлась европейской версией ОКС7, в то время как на североамериканском континенте гораздо раньше начала внедряться другая подсистема - ISUP. В дополнение к управлению основными телефонными услугами TUP определяет процедуры и форматы для дополнительных услуг. Однако, в силу самой природы ISDN, дополнительные услуги, определенные в ISUP, являются более мощными и используют более современные решения, чем те, которые определены для TUP.

Подсистема пользователя данных DUP была определена на ранней стадии разработки ОКС7 для управления установлением и разъединением соединений передачи данных с коммутацией каналов. Распространение DUP весьма незначительно, и только немногие операторы сети реализовали выделенные сети передачи данных с коммутацией каналов. Требования к передаче данных сегодня удовлетворяются за счет ISUP, в результате чего широкое использование DUP в сетях электросвязи маловероятно.

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

Подсистема ISUP поддерживает два класса услуг: базовый и дополнительные виды обслуживания. Базовый класс услуг обеспечивает установление соединений для передачи речи и/или данных. Дополнительные виды обслуживания представляют собой все остальные, ориентированные на соединение услуги, связанные, иногда, с передачей сообщений уже после установления основного соединения.

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

Сообщения ISUP передаются в поле SIF значащих сигнальных единиц, как показано на рис. 10.12. Верхняя строка на этом рисунке идентична формату значащей сигнальной единицы MSU на рис. 10.2, который представляется полезным напомнить читателю. Поле сигнальной информации состоит из этикетки маршрутизации, кода идентификации канала, типа сообщения и параметров. Параметры подразделяются на обязательную фиксированную часть, обязательную переменную часть и необязательную часть, как это имело место для SCCP и было показано на рис. 10.6. Код идентификации канала (CIC) указывает номер разговорного канала между двумя станциями, к которому относится сообщение. Так, если используется цифровой тракт 2.048 Мбит/с, то пять младших битов CIC кодируют в двоичном виде речевой временной интервал. Оставшиеся же биты используются, когда необходимо определить, какому ИКМ- потоку принадлежит данный речевой интервал.

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

Любое сообщение включает ряд параметров. Каждый параметр имеет название, которое кодируется одним байтом. Длина параметра может быть фиксированной или переменной. Как это имело место для БССР, предусмотрены следующие три категории параметров: фиксированные обязательные, переменные обязательные, необязательные.

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

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

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

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

Рис. 10.13. Структура параметров в ISUP

Для ISUP специфицированы ряд типов сообщений и параметров. Примерами таких типов сообщений являются:

Начальное адресное сообщение (IAM), . запрос информации (INR),

Сообщение о принятии полного адреса (АСМ),

Сообщение ответа (ANM),

Подтверждение выполнения модификации соединения (CMC), . отказ модифицировать соединение (RCM),

Блокировка (BLO),

Подтверждение блокировки (BLA),

Сообщение ответа от абонентского устройства с автоматическим ответом (например, терминал передачи данных) (CON),

Сообщение ответа (ANM),

Освобождение (REL),

Завершение освобождения (RLC) и др.

Для российской версии протокола ISUP введены некоторые дополнительные сообщения , которые должны быть упомянуты здесь, несмотря на отрицательное отношение автора книги к целесообразности их введения. Это дополнительное сообщение об отбое вызывающего абонента (CCL) для поддержки процедуры двустороннего отбоя с целью определения номера вызывающего абонента после отбоя при злонамеренном вызове. Введены также сообщение об оплате (CRG), которое передается в обратном направлении после сообщения ANM или CON с целью тарификации вызова, и сообщение посылки вызова (RNG), которое передается в начале каждой посылки вызова при входящем полуавтоматическом соединении (повторный вызов). Все эти ситуации достаточно подробно рассматривались в предыдущих главах.

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

Фиксированный обязательный параметр длиной 1 байт определяет природу устанавливаемого соединения. Этот параметр характеризует статус устанавливаемого соединения, например, наличие или отсутствие эхозаградителя, включение в соединение спутникового канала и т.п.

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

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

Последний фиксированный обязательный однобайтный параметр описывает требования к среде передачи, например, запрашивается канал 64 Кбит/с.

В адресном сообщении IAM имеется один обязательный переменный параметр длиной 4-11 байт, определяющий номер вызываемого абонента (например, набираемые цифры номера), а также необязательные параметры: номер вызывающего абонента длиной 4-12 байт и непосредственно информация «пользователь-пользователь» длиной 3-131 байт, позволяющая абонентам обмениваться данными в ходе процедуры установления соединения.

Сообщение о принятии полного адреса АСМ передается входящей станцией для индикации успешного получения достаточного количества цифр для маршрутизации вызова к вызываемому абоненту. Тип сообщения АСМ кодируется 00000110.

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

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

Кроме этого, в АСМ могут включаться необязательные индикаторы вызова в обратном направлении длиной 3 байта и информация «пользователь - пользователь» длиной 3-131 байт, как описано для IAM.

Как видно из приведенных выше примеров, ISUP широко использует поля необязательных параметров, тем самым увеличивая гибкость предоставляемых операторами сети услуг. Однако такая гибкость, с другой стороны, увеличивает затраты на анализ сообщений в АТС. Например, рассмотренное выше сообщение IAM согласно спецификации ITU-T может содержать до 14 необязательных параметров и до 131 байта информации пользователь-пользователь. Такой размер некоторых сообщений ISUP может вызвать проблемы, если в одно сообщение одновременно включено слишком много необязательных полей. Кроме того, гибкий подход к необязательным полям сам по себе требует дополнительной обработки для определения, какая информация присутствует в конкретном сообщении, а какая нет.

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

Рис. 10.14 иллюстрирует процедуру установления и разъединения базового соединения. При приеме запроса установления соединения от вызывающего абонента исходящая АТС А анализирует информацию о маршруте и формирует начальное адресное сообщение IAM. Анализ номера вызываемого абонента позволяет исходящей АТС А определить направление маршрутизации вызова. В приведенном на рис. 10.14 примере вызов направляется к транзитной АТС В. Информация в фиксированном обязательном параметре IAM указывает на тип требуемого вызывающим абонентом соединения - соединение 64 Кбит/с. Эта информация посылается к транзитной АТС В, в результате чего соответствующий разговорный тракт проключается в обратном направлении к вызывающему абоненту.

© - проключение разговорного тракта в обратном направлении - проключение разговорного тракта

Q - проключение разговорного тракта в прямом направлении О - освобождение разговорного тракта Рис. 10.14. Установление и разъединение базового соединения в ISUP

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

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

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

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

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

В отличие от TUP, как вызывающий, так и вызываемый абоненты могут инициировать немедленное разъединение соединения, т.е. ISUP использует метод одностороннего отбоя. На рис. 10.14 вызывающий абонент А первым направляет сигнал разъединения к исходящей АТС А. Исходящая АТС начинает разъединение соединения и передает сообщение об освобождении REL на транзитную станцию В, которая передает сообщение освобождения входящей АТС Б и начинает освобождение разговорного тракта. После освобождения разговорного тракта и готовности к обслуживанию нового вызова транзитная АТС В посылает сообщение об окончании освобождения RLC на исходящую АТС А. Точно так же при приеме сообщения освобождения REL выполняется разъединение разговорного тракта на входящей АТС Б.

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

Первоначальные спецификации ISUP определяли тройную последовательность передачи сообщений разъединения: сообщение освобождения (REL - release), запрос разъединения (RLSD - realesed) и окончание освобождения (RLC - release complete). Эта процедура была заменена процедурой, описанной выше и максимально унифицированной с процедурами разъединения SCCP.

Подсистема ISUP поддерживает целый ряд дополнительных возможностей для телефонных услуг и услуг передачи данных, которые не обеспечивает TUP. Некоторые из таких дополнительных возможностей реализуются в российской АТСЦ-90 и приводятся в табл. 10.2 в качестве примера.

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

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

Основные процедуры переадресации вызова сходны с услугой переадресации вызова в TUP. Однако организация переадресации вызовов в ISUP может инициироваться в трех различных режимах: при занятости вызываемого абонента (1), когда нет ответа от вызываемого абонента в течение определенного времени (2) и для всех вызовов без дополнительных условий (3).

Таблица 1G.2. Некоторые дополнительные услуги ISUP

Термин «интегрированные системы управления предприятием» (ИСУП) в начале нынешнего десятилетия ввела в обиход аналитическая компания IDC вместо ранее использовавшегося в подобных исследованиях понятия ERP (Enterprise Resource Planning — планирование ресурсов предприятия). В основе ИСУП лежит принцип создания единого хранилища данных (репозитария), содержащего всю деловую информацию, накопленную организацией в процессе ведения бизнеса, в частности финансовую информацию, данные, связанные с производством, управлением персоналом, и любые другие данные. Наличие репозитария избавляет от необходимости передавать данные от приложения к приложению. Кроме того, любая часть информации, которой располагает данная организация, становится одновременно доступной для всех работников, обладающих соответствующими полномочиями.

Концепция ИСУП нашла широкое применение, поскольку планирование ресурсов позволяло сократить время выпуска продукции, снизить уровень товарно-материальных запасов, а также улучшить обратную связь с потребителем при одновременном сокращении административного аппарата. Все это позволило объединить все ресурсы предприятия и повысить эффективность управления ими. Исторически концепция ИСУП стала развитием более простых концепций MRP (Material Requirement Planning - планирование материальных потребностей) и MRP II (Manufacturing Resource Planning - планирование производственных ресурсов). Используемый в ИСУП программный инструментарий позволяет проводить производственное планирование, моделировать поток заказов и оценивать возможность их реализации в службах и подразделениях предприятия, увязывая его со сбытом.

Как правило, ИСУП включает следующие элементы:

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

К основным функциям ИСУП можно отнести:

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

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

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

В начале 2010 года подразделение корпорации Microsoft в России представило результаты исследования уровня зрелости ИСУП-решений, используемых различными российскими компаниями. Исполнителем проекта выступала компания IDC. В ходе исследования были опрошены 50 бизнес-руководителей и 100 ИТ-руководителей из 120 компаний. Опрос проводился в наиболее показательном для российского рынка срезе компаний с годовым оборотом от 50 до 500 млн. долл. Региональная структура выборки: Москва - 52%, остальные регионы - 48%. Отраслевая структура выборки: розничная торговля - 22%, промышленное производство - 20%, производство продуктов питания - 15%, дистрибуция - 16%, транспорт - 14%, телекоммуникации и СМИ - 13%. Исследование показало, что среднее значение индекса зрелости ИСУП-рынка составило 55%. Наименьший результат оказался равен 20%, а наивысший - 95%. Только 38% компаний показали уровень индексов проникновения и эффективности выше средних значений. Еще у 24% компаний эффективность оказалась достаточно высока при низком уровне проникновения. Эффективность оставшихся 38% компаний была оценена как низкая, причем 15% компаний показали невысокие значения, как индекса эффективности, так и индекса проникновения ИСУП. На практике это означает, что 62%, или почти двум третям, предприятий следует предпринять шаги, направленные на оптимизацию существующих бизнес-приложений. Невысокая степень реализации потенциала внедренных решений связана с тем, что многие предприятия относятся к внедрению ИСУП как техническим, а не бизнес-проектам, считают авторы исследования. Основной задачей проектов создания корпоративных систем управления по-прежнему остается автоматизация управления бухгалтерией, финансами, персоналом, расчётом заработной платы. Относительно немногие компании пытаются решать с помощью ИСУП стратегические проблемы. Такие задачи, как финансовый и стратегический анализ, бизнес-аналитика, управление проектами, оказываются в списке целей проектов внедрению ERP менее чем в половине случаев.

В последние пять лет перед кризисом российский рынок ИСУП рос более высокими темпами, чем даже прогнозировали эксперты (фактический объем 2008 г. превышал пятилетнее предсказание IDC на 40%). На рынке четко обозначилась пятерка компаний-лидеров (в алфавитном порядке): 1С, Microsoft, Oracle, SAP и «Галактика». По данным исследования IDC (Russia Enterprise Application Software 2010-2014 Forecast and 2009 Vendor Shares), объём российского рынка интегрированных систем управления предприятием (ИСУП) в 2009 году составил 492,18 млн. долл., что соответствует снижению на 18,9% по сравнению с предыдущим годом. Эксперты полагают, что снижение было обусловлено, в первую очередь, кризисными явлениями в российской экономике, особенно в первой половине 2009 года. Сокращение ИТ-бюджетов крупных компаний привело к значительному уменьшению числа новых полномасштабных проектов по внедрению ИСУП. Существенно снизился спрос на решения ИСУП в сегменте малых и средних предприятий. Вместе с тем обширная база существующих клиентов, проекты по внедрению отдельных функциональных модулей, а также существенно возросший спрос на решения бизнес-аналитики со стороны крупных компаний позволили избежать значительного падения рынка ИСУП в условиях, когда российский рынок ИТ в целом сократился более чем на треть.

Лидером российского рынка ИСУП в 2009 году стала компания SAP, доля которой составила 50,1%. 1С и Oracle закончили год с 22,3% и 9,6% рынка и заняли второе и третье место соответственно. Microsoft Dynamics с 7,1% стала четвертой. Доля рынка Microsoft Dynamics отображена с учетом корректировки доходов компании на российском рынке ИСУП за 2008 год в соответствие с более точной информацией, полученной от поставщиков. Согласно корректировке, доля компании в 2008 году составила 6,9%. «Галактика», занявшая 3,9% рынка, замыкает пятёрку лидирующих поставщиков. Суммарная доля российских компаний в группе лидеров составила 26,2%, превысив аналогичные показатели предыдущего года. Ведущей отраслью для российского рынка ИСУП в 2009 году осталось непрерывное производство. Второе место, как и в предыдущем году, было за розничной торговлей. На третьем месте в списке наиболее прибыльных для поставщиков ИСУП отраслей осталось дискретное производство. На четвертой и пятой позициях - оптовая торговля и энергетика.

В IDC считают, что российский рынок ИСУП в ближайшие пять лет будет ежегодно расти в среднем на 15,1%. Наиболее заметный рост будет наблюдаться в госсекторе и здравоохранении. Правительство планирует значительные затраты на развитие концепции электронного правительства и автоматизацию государственных медицинских учреждений. Темпами, опережающими средние показатели рынка, будут увеличиваться затраты в секторах энергетики, финансов, оптовой и розничной торговли, бизнес-услуг, дискретного производства, образования, сельского хозяйства, строительства и добывающей промышленности.

Ведущие поставщики крупных ИСУП, к сожалению, представлены на Softool далеко неполно, хотя в ряде случаев на выставке есть их партнеры, продвигающие соответствующие продукты. Так, на Softool 2009 российский рынок ИСУП был представлен 36 компаниями, которые позиционировали себя, как поставщики и/или разработчики подобных решений. При этом доля региональных компаний составила примерно 9%. В частности, это компании Tandem (Новосибирск), «Градиент - Новые технологии» (Ижевск), «РЕЛЭКС» (Воронеж), «СКБ Контур» (Екатериндбург).

Информационная система управления проектами [англ. - Project Management Information System]. Успешная и продуктивная проектная деятельности организации невозможна без применения информационных технологий. С целью автоматизации процессов и консолидации данных управления проектами выступает информационная система управления проектами, которая представляет собой сбалансированный организационно-технологический комплекс программных, технических и информационных средств и инструментов, направленный на реализацию, поддержку и повышение эффективности процессов управления проектами. ИСУП является неотъемлемой частью корпоративной системы управления проектами (КСУП).

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

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

Разнообразие информационных систем управления проектами

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

• Локальные информационные системы управления проектами. В основном предназначаются для малого бизнеса, частных предпринимателей и компаний, в которых практически нет проектной деятельности, за исключением одного - двух небольших проектов. Плюсы таких систем в дешевизне и доступности. В качестве примера можно привести Microsoft Project Standart или Professional, Open Project и д.р.
• Серверные информационные системы управления проектами. Глобальное решение, ориентированное на средний и крупный бизнес, в задачи которого входит автоматизация проектного управления на уровне проекта, программы, портфеля проектов (или нескольких портфелей) и автоматизация процессов проектного офиса. Данные системы сильно распространенны в мире, и большинство ведущих компаний используют именно их, для управления проектами. Минусы в дороговизне внедрения и сопровождения, необходимость укомплектовывать штат компании. Лидерами таких систем являются Oracle Primavera, HP Project and Portfolio Management Center, Enterprise Project Management Solutions. Кстати многие из этих систем уже сегодня предоставляют решение на основе интернет технологий, как описано ниже.
• Информационные системы управления проектами на основе интернет технологий. Современный подход к предоставлению услуг, по функционалу не отличающийся от серверных решений, но позволяющий компаниям не внедрять у себя это решение, закупая много специального оборудования (компьютеры, сервера) и формируя штат персонала поддержки и сопровождения, а использовать современный подход - облачные технологии на основе которых сторонняя компания удаленно предоставляет необходимый функционал, что позволяет использовать мощности поставщика услуг и снижает затраты на внедрение и сопровождение. Минусы заключаются в том, что Вы передаёте всю информацию по проектной деятельности сторонней компании, которая отвечает за их безопасность и эти системы на сегодняшний день не столь функциональны, нежели серверные решения, а также они менее настраиваемые. Как пример можно привести такие решения - IBN, COMINDWORK, МЕГАПЛАН.

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

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

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

Первые программы управления проектами представляли собой достаточно примитивные инструменты, позволяющие планировать отдельные проекты и контролировать ход их реализации, однако сегодня они способны контролировать сложнейшие проекты, содержащие миллионы работ, десятки и сотни тысяч ресурсов. Наиболее популярная информационная система управления проектами: и SureTrak от компании Primavera Systems. Параллельно с системами календарно-сетевого планирования компания развивала и другие сопутствующие проектно-ориентированные программные продукты, такие как Primavera Expedition, который основан на процессном подходе и предназначен для управления договорными обязательствами между участниками проектов, контроля разработки и выпуска проектно-сметной и разрешительной документации, а также информационной поддержки переговорных процессов по проектам.

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

Корпоративная информационная система управления проектами

Серия программных продуктов Primavera Enterprise, позволяет создать корпоративную систему управления проектами и включает ряд систем, работающих с единой базой данных, но предоставляющих различную функциональность. Ядром является программный продукт Primavera Project Planner for the Enterprise (P3e), предоставляющий обширный набор функций и предназначенный для групп планирования и служб мониторинга проектов, которые должны иметь возможность в любой момент вносить необходимые изменения по проектам — от переопределения технологии выполнения работ (последовательности и логики их выполнения) и сдвигов сроков, до перераспределения ответственных, а также решения ресурсных конфликтов.

Имеются дополнительные программные продукты, например, специализированный модуль Portfolio Analyst, обеспечивающий возможность формирования разнообразной аналитики и контроля отдельных проектов или портфелей проектов по заданным показателям. При необходимости Portfolio Analyst позволяет опускаться и на более детальные уровни информации по проектам, например, анализ загрузки ресурсов, потребности в материалах по отдельным пакетам работ. Исполнители работ по проектам могут использовать специальные приложения для сбора информации о проделанной работе. Причем, что немаловажно для компаний с территориально распределенными проектами, эти приложения позволяют работать, используя Internet-приложение (Progress Reporter), или, если это технически сложно, просто вводить информацию в карманный компьютер (Primavera Mobile) для её последующей передачи в общую базу.

Однако задачи удаленной работы с проектом не ограничиваются сбором информации от исполнителей. Когда ключевые участники проекта физически размещаемые в разных точках, должны слаженно работать и получать точные оперативные данные о прогрессе проекта, им на помощь приходит продукт Primavision, обеспечивающий on-line доступ к детальной информации по проекту. А, формируемый в полуавтоматическом режиме сайт проекта (Project Website), предоставит отчетную информацию по проекту для заказчиков и инвесторов.

Интеграционные решения

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

Новые версии Primavera Expedition совместимы с серией Primavera Enterprise и позволяют расширить возможности корпоративной системы управления проектами в части контроля выполнения договорных обязательств, мониторинга выпуска и согласования проектно-сметной документации и сопровождения переговоров по проектам. Кроме этого, поддерживается работа с СУБД Oracle, что облегчает решение интеграционных задач.

Но и при таком наборе инструментов все задачи предприятия охватить трудно, кроме того, во многих компаниях уже функционируют различные системы: бухгалтерские программы, системы документооборота, трехмерного проектирования, сметные программы и т. д. — при создании корпоративной системы управления было бы большой ошибкой не использовать накопленную в них информацию. В этой связи одним из направлений деятельности компании Primavera является интеграция с программным обеспечением других производителей — текущий перечень партнеров компании насчитывает более сотни поставщиков, специализирующихся в смежных областях деятельности: управлении ресурсами, процессами, поставками и т.д. Среди зарубежных партнеров можно упомянуть SAP, Oracle, PeopleSoft и J.D. Edwards, а также поставщиков систем трехмерного проектирования Bentley и Intergraph.

В России используются как интеграционные модули, разработанные совместно с зарубежными производителями, так и собственные решения, специфичные для местного рынка. Одним из примеров является совместная разработка компаний «ПМСофт» и «Инфострой», обеспечивающая передачу информации из стандартных строительных смет в календарно-сетевой график проекта. Этот программный продукт работает со сметной программой «А0» и системой Primavera Project Planner. Проблемы интеграции систем календарно-сетевого планирования и сметных программ хорошо известны: прежде всего это несоответствие уровней детализации сметы и календарно-сетевого графика. При составлении сметы определяется стоимость строительства на основе объемов работ, поэтому сметчики часто не учитывают план производства работ, объединяя, например, в одной расценке одинаковые работы по всему объекту, что не удобно с точки зрения управления.

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

Другой пример интеграционного решения основан на экспорте данных из типового проекта на базе сметной программы WinAvers.

Потребность в подобных решениях и их разнообразие инициировали работы по интеграции системы Primavera Enterprise и с другими современными сметными системами.

Еще один пример — интеграция Primavera Expedition и информационных систем российской компании «ТрансИнвестИнтегратор », реализованной для учета договоров и первичных документов на ряде предприятий атомной энергетики в России. В настоящее время разработанное решение находится на стадии тестирования.

Отдельного внимания заслуживает программный продукт OSIRIS, который является развитием известной российским пользователям утилиты Primavera Post Office и ее аналога „ПМ Почта“ для Primavera Project Planner. Приложение OSIRIS направлено на поддержание оперативного и эффективного взаимодействия между группой управления проектом и его исполнителями. Используя модули, составляющие приложение OSIRIS, участники проекта могут осуществлять детальное планирование на местах проведения работ, вносить фактические данные и обновлять информацию по статусу выполняемых ими работ, а также вносить свои предложения и комментарии в ходе реализации проекта.

Для работы с OSIRIS, пользователи не нуждаются в покупке дополнительного программного обеспечения и прохождении обучения — обмен данными по проекту осуществляется по электронной почте. Приложение OSIRIS связано с центральной корпоративной базой данных проектов Primavera Enterprise, из которой происходит рассылка заданий исполнителям по проекту для детального планирования работ и обновления информации по статусу на местах. Далее, обновленная информация отправляется обратно и поступает в основной модуль OSIRIS Administrator, в котором она проходит утверждение группой управления проектами. Если группу управления устраивают полученные результаты, то она обновляет информацию в корпоративной базе данных, в противном же случае полученные данные отправляются на доработку.

По аналогии с программой Progress Reporter, OSIRIS позволяет собирать фактическую информацию о выполнении работ по проектам, но в отличие от Progress Reporter, работает независимо от базы данных проектов и не требует постоянного подключения к ней.

Вместе с программным обеспечением Primavera поставляются средства разработки приложений, позволяющие осуществлять интеграцию с другими решениями, настроить модуль передачи данных из приложений Primavera в другие программные продукты и, наоборот, при этом, работа с данными осуществляется на более высоком уровне, c учетом всех бизнес правил приложения, что обеспечивает сохранность логической модели данных. С помощью Primavera SDK возможна интеграция пакетов Primavera Enterprise/Primavera TeamPlay с пользовательскими базами данных и приложениями. Для этого используется интерфейс ODBC, OLE-DB и JDBC. ODBC-клиентами поддерживаются стандартные языки программирования VB, PowerBuilder, C++ и т.д. Primavera SDK делает программное обеспечение открытым для написания интеграционных модулей с любыми внешними приложениями. Работа с Primavera SDK осуществляется с помощью стандартного языка SQL.

Управление распределенными проектами

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

Корпоративная система обязана предоставлять возможность для работы распределенных или удаленных участников проектов. Уже упоминался ряд программных продуктов Primavera, которые позволяют обеспечить удаленный доступ к информации по проекту, её просмотру и обновлению в ограниченном объеме. Но, если удаленные группы должны иметь полный доступ к проекту: корректировать график, обновлять структуры кодов или инициировать новые проекты, тогда центральный модуль Primavera Project Planner for the Enterprise должен работать как на офисных, так и на удаленных рабочих станциях одновременно. Существует несколько путей решения этой задачи, например, построение сети терминальных рабочих станций на базе технологии Citrix MetaFrame. Эта технология позволяет получить полнофункциональный доступ к приложениям P3e и Primavera Expedition посредством тонкого клиента, например, при подключении через стандартный модем, при этом достигается максимальная степень сохранности данных, которые постоянно остаются в пределах центральной базы данных.

Перспективы

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

Практически все системы управления проектами берут за основу некий план, составляемый на предварительном этапе. Затем в соответствии с этим планом автоматически организуются выполнение, анализ и управление рабочими этапами плана, пакетами работ и самими работами. Методологии систем автоматизации деловых процессов (САДП) и СУП, несмотря на различие в масштабах автоматизируемых действий, в известной степени перекликаются, что позволяет установить двустороннюю синхронизацию между схемами workflow и стратегическим планом (в виде календарносетевого плана или графика выполнения работ по проекту). Здесь важно отметить, что в рамках системы управления проектами календарное планирование и ход выполнения этапов происходят в полуавтоматическом режиме, а интеграция с workflow-системой позволяет создать корпоративную систему управления проектами. Перед такой системой стоит несколько задач: возможность управлять одновременно группой проектов; возможность управлять взаимосвязями проектов; анализ портфеля (группы) проектов; поддержка возможности выбора проекта по заданным критериям; возможность использования лучшего практического опыта; контроль выполнения проекта и т.д.

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

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

Алексей Лысаков,
Александр Цветков
Компания «ПМСофт»

Просмотры: 6 220

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

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

Реинжиниринг обладает следующими свойствами:

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

Реинжиниринг применяется в трех основных ситуациях:

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

Основные этапы реинжиниринга:

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

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

Информационные системы управления предприятием (ИСУП)

Начнем с определений, необходимых для понимания дальнейших рассуждений. Последовательное рассмотрение этих определений дает возможность войти в необходимую современному менеджеру область информационных систем управления предприятием (ИСУП).

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

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

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

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

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

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

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

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

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

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

Преимущества неавтоматизированных (бумажных) систем:

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

Преимущества автоматизированных систем:

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

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

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

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

1. Эскиз проекта. Подробное описание целей и задач проекта, доступных ресурсов, ограничений и т.п.
2. Оценка проекта. Определяется, что будет делать система, как будет работать, какие аппаратные и программные средства будут использоваться, как они будут обслуживаться. Готовится список требований к системе, изучаются потребности постоянных пользователей.
3. Построение и тестирование. Персонал должен убедиться, что с ИС удобно работать, до того, как она станет основой деятельности.
4. Отладка и внедрение. Проект не завершен до тех пор, пока менеджер проекта не сможет продемонстрировать, что ИС работает надежно.

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

Жизненный цикл ИС разделяется на следующие стадии:

• предпроектное обследование;
• проектирование;
• разработка ИС;
• ввод ИС в эксплуатацию;
• эксплуатация ИС;
• завершение эксплуатации ИС.

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

Задачи ИСУП

Управление предприятиями в современных условиях требует все большей оперативности. Поэтому использование информационных систем управления предприятием (ИСУП) является одним из важнейших рычагов развития бизнеса.

Частные задачи, решаемые ИСУП, во многом определяются областью деятельности, структурой и другими особенностями конкретных предприятий. В качестве примеров можно сослаться на опыт создания ИСУП для предприятия - оператора связи и опыт внедрения партнерами фирмы SAP системы R/3 на ряде предприятий СНГ и дальнего зарубежья.При этом примерный перечень задач менеджмента, которые должна решать ИСУП на различных уровнях управления предприятием и для различных его служб, к настоящему времени можно считать общепризнанным среди специалистов. Он приведен в табл.5.1 . При решении этих задач широко используются различные методы теории принятия решений , в том числе эконометрические и оптимизационные.