Гущин А.Н. Информационные технологии в экономике

Подождите немного. Документ загружается.

производство, что подразумевает проектное планирование и управление. Тогда на

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

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

предприятием в целом, информационная система должна "уметь" работать с каждым

из этих типов производств. Поэтому системы класса ERP содержат набор модулей,

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

Обеспечение многозвенного производственного планирования

Большие производственные объединения, распределенные территориально, могут

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

Каждый филиал, как правило, имеет отдельный законченный производственный

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

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

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

предотвратить простои и перегрузки отдельных производств из-за не поставленных

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

подразделений компании должны быть согласованы между собой.

Логика работы заложенных в ERP-системы средств агрегирования планов

проста. Сначала формируются собственные планы закупок/поставок и производства

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

план-графиках закупок и производства по каждой номенклатурной единице,

входящей во внутрипроизводственную сеть поставок, указываются источник

(потребитель) и приоритетность поставки этой единицы. Затем создается

многозвенный (агрегированный) план. Для этого ERP-система обобщает потребности

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

поставок, и генерирует производственные планы для каждого звена с учетом

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

система проводит сценарную оценку их выполнимости. Как и в обычных MRP II-

системах, оценка выполнимости планов происходит путем создания системой потока

заказов зависимого спроса на уровне всего производственного объединения. При

выявлении критических состояний планы корректируются, и лишь затем поступают

на утверждение.

Расширение сферы интегрированного планирования ресурсов

В классических MRP II-системах интегрированное планирование ресурсов

охватывало лишь производственные, складские, снабженческие и сбытовые

подразделения предприятия. Действия других тесно связанных с производственным

процессом подразделений и служб (например, ремонтных, транспортных) не

вовлекались в планирование. Точно так же за кадром оставались проектные работы.

ERP-системы позволяют вовлечь в сферу интегрированного планирования ресурсов

все подразделения предприятия, так или иначе эти ресурсы использующие. Это

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

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

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

подсистемы.

· Планирование и управление реализацией производственных проектов. В этой

подсистеме ведется анализ проекта (разработка его структуры, выделение

подпроектов, разбиение подпроектов на отдельные работы), формирование

сетевых графиков работ, планирование материальных и трудовых ресурсов,

оборудования, финансовых затрат для выполнения этих работ, управление ходом

их выполнения.

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

планировать ресурсы и оптимизировать выполнение работ по техническому

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

влияние на работу модуля планирования производства. Если проводится

аварийный или плановый ремонт некоторой единицы производственных

мощностей, то подсистема должна оповестить модуль планирования

производства о блокировке данной единицы производственных мощностей на

определенный период и указать на этот период альтернативный

производственный маршрут.

· Планирование и управление распределенными ресурсами (Distribution Resources

Planning). Такая подсистема предоставляет возможность работать со сложной

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

компетенцию входит и планирование работы транспортных служб. С помощью

подсистемы можно:

§ минимизировать транспортные затраты на доставку сырья и

комплектующих;

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

продукции по складам компании;

§ выбрать оптимальные транспортные маршруты при проведении

межскладских перемещений (когда есть несколько складов) или

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

дилерских организаций).

§ Планирование и управление послепродажным и специальным

обслуживанием. Как следует из названия, подсистема предназначена

для управления всеми видами сервисных услуг.

Здесь нужно отметить важную деталь. Во многих современных MRP II-системах

появляются подсистемы "Проект", "Сервис", "Транспорт" и т. д. Однако, хотя в этих

подсистемах и ведется учет затрат и доходов, бюджетирование, зачастую в них нет

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

интегрированное планирование потребностей в ресурсах и мощностях в масштабах

всего предприятия.

Несмотря на довольно широкую функциональность, ERP-системы не являются

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

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

производственным процессом, однако не укладывается в существующую идеологию

MRP II- / ERP-систем. Для автоматизации работы таких подразделений используются

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

(САПР), системах конструкторской и технологической подготовки производства

(PDM-системы - Product Data Management). Поэтому реально ERP-системы (так же,

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

подсистемами.

Планирование и учет корпоративных финансов

Реализация в ERP-системах поддержки планирования ресурсов разветвленной

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

сложными финансовыми потоками и возможности корпоративной консолидации.

Поэтому в ERP-системы входят мощные системы управления корпоративными

финансами, характеризующиеся следующими особенностями:

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

финансовые данные как на уровне отдельных подразделений-звеньев, так и на

уровне всей компании;

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

систем бухгалтерского учета и отчетности;

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

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

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

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

ведение истории отношений с кредиторами, анализа состояния их дел, поиск

сведений о них;

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

Включение в системы мощных средств поддержки принятия решений

Управленческие решения принимаются людьми. Сама по себе ERP-система не является

инструментом для принятия управленческих решений, она лишь поставляет

необходимую для этого информацию. Реальную же поддержку принятия

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

ERP-системы (обычно эти средства называют OLAP). Приведем некоторые возможности

систем поддержки принятия решений:

· отслеживание эффективности работы различных участков и служб для выявления

и устранения слабых звеньев, а также для совершенствования структуры бизнес-

процессов и организационных единиц;

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

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

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

деятельности предприятия для выделения перспективных и убыточных

направлений бизнеса;

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

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

В настоящее время практически все разработчики MRP II- / ERP-систем

относят свои системы к классу ERP. "ERP" - очень модная аббревиатура, способная

увеличить продажи системы, по сути не принадлежащей к этому классу. Дело

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

со слабым производственным блоком как "полноценные ERP-системы", вводя

потребителей в заблуждение. Эта путаница усугубляется отсутствием ERP-стандарта.

Чуть выше были описаны характеристические черты 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-системы.

CRM (Customer Relationship Management System) – система управления

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

характеристика. Выполняемые функции. Достоинства и недостатки.

CRM-система - система управления взаимодействием с клиентами) —

корпоративная информационная система, предназначенная для улучшения

обслуживания клиентов путём сохранения информации о клиентах и истории

взаимоотношений с клиентами, установления и улучшения бизнес-процедур на

основе сохранённой информации и последующей оценки их эффективности. Её

основные принципы таковы:

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

все сведения обо всех случаях взаимодействия с клиентами;

· синхронизированность управления множественными каналами

взаимодействия (то есть существуют организационные процедуры, которые

регламентируют использование этой системы и информации в каждом

подразделении компании);

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

соответствующих организационных решений — например, приоритетизации

клиентов на основе их значимости для компании.

Таким образом, этот подход подразумевает, что при любом взаимодействии с

клиентом по любому каналу, сотруднику организации доступна полная информация

обо всех взаимоотношениях с клиентами и решение принимается на её основе,

информация о котором, в свою очередь, тоже сохраняется и доступна при всех

последующих взаимодействиях.

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

обработки информации. По функциональности выделяют блоки:

· Продажи

· Маркетинг

· Сервисное обслуживание

По уровням обработки информации:

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

по Контактам, Компаниям, Проектам, Документам и т. д.

· Аналитический — отчетность по первичным данным и самое главное более

глубокий анализ информации в различных разрезах (воронка продаж, анализ

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

разрезе продуктов, сегментов клиентов, регионов и т. п.)

· Коллаборационный (англ. collaboration - сотрудничество; совместные,

согласованные действия) — уровень организации тесного взаимодействия с

конечными потребителями, клиентами, вплоть до влияния клиента на

внутренние процессы компании (опросы, для изменения качеств продукта или

порядка обслуживания, web-страницы для отслеживания клиентами состояния

заказа, уведомление по SMS о проведённых транзакциях по банковскому

счету, возможность для клиента самостоятельно скомплектовать и заказать в

online к примеру автомобиль или компьютер из доступных блоков и опций и

др.)

Ранее (до 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.

Этап системного анализа и проектирования рассматривался

обязательным этапом работ, который должен предварять все

последующие и определял "фундамент для обеспечения функциональной

адекватности и качества" разрабатываемой информационной системы.

От качества системного анализа и проектирования непосредственно зависит степень

удовлетворенности заказчика от внедренной информационной системы, особенно,

если речь идет о корпоративных информационных системах (КИС).

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

и проектирования выделяют три фазы:

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

и выявление ее недостатков;

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

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

· разработка системного проекта комплекса программ и баз данных,

определяющих методы и средства дальнейшего детального проектирования и

всего жизненного цикла информационной системы и базы данных.

К этому списку необходимо добавить, что эти фазы применимы не только к

организациям уже имеющим какие то информационные системы, но и к тем, в

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

проектирования является наиболее важным для успешного выполнения проекта, и

поэтому может рассматриваться как один из факторов риска. Естественно, что эту

работу могут выполнить либо специализированные организации, имеющие опыт

подобных проектов, либо собственные аналитические структуры, знающие бизнес-

процессы компании лучше внешних подрядчиков. Но наиболее эффективным

представляется комбинированная проектная группа. В любом случае, в

формировании требований заказчика в той или иной степени участвуют и

разработчик и заказчик.

На этапе системного анализа и проектирования при сравнительно малых затратах

можно достичь следующих результатов:

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

организации;

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

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

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

информационной системе;

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

системы;

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

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

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

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

базовой версии информационной системы;

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

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

С движением по этапам процесса разработки, возрастает стоимость ошибки. Это еще

раз подчеркивает необходимость проведения обследования - что снижает

вероятность принятия неправильных проектных решений. Особенности, характерные

для крупных проектов КИС. Это:

· сложность описания (достаточно большое количество функций, процессов,

элементов данных и сложные взаимосвязи между ними), требующая

моделирования и анализа данных и процессов;

· наличие совокупности тесно взаимодействующих компонентов (подсистем),

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

традиционных приложений, связанных с обработкой транзакций и решением

регламентных задач, и приложений аналитической обработки (поддержки

принятия решений), использующих нерегламентированные запросы к данным

большого объема;

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

приложений;

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

платформах

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

квалификации и сложившимся традициям использования тех или иных

инструментальных средств.

Следует сказать, что особенность в) выдвигает требование обязательного создания

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

цикла программного обеспечения (ЖЦ ПО) и критериев применимости ПО, согласно

которым производится отсев существующих и разработка новых приложений

(подсистем). Особенность г) выдвигает требование использования системного ПО

класса middleware, позволяющего без излишних затрат создавать и эксплуатировать

многоплатформенные подсистемы. Особенности а),б),д) приводят к необходимости

использования единой методики и средств системного анализа и проектирования,

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

участников проекта. Именно такая методика является объектом анализа данной

статьи.

КИС как объект проектирования

Когда говорят о КИС, то подразумевают системы для крупных, территориально

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

Обязательным свойством КИС является ее системность, то есть понимание КИС как

объекта, имеющего новое системное свойство, которым не обладают отдельные

компоненты.

Под бизнес-процессом будем понимать цепочку работ, которые

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

Компоненты КИС предназначены для автоматизации большей части бизнес-

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

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

клиента);

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

основного бизнес-процесса или организации).

В большинстве случаев основные бизнес-процессы в первом приближении

идентичны для организаций, принадлежащих одной отрасли (например,

нефтепереработка для НПЗ, продажи для торговых организаций), или вообще

являются уникальными (например, трубопроводный транспорт нефти, транспорт

газа). Для автоматизации таких процессов существуют отраслевые решения

(например, SCADA системы диспетчерского управления, системы для химического

производства, системы для транспортных организаций) или специально

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

Вспомогательные же бизнес-процессы практически идентичны на верхнем

уровне абстракции во всех организациях (например, бухгалтерия, логистика, склад,

кадры и т.п.), а существующие различия проявляются на нижних уровнях

детализации. Такие бизнес-процессы очень хорошо изучены и формализованы.

Существует большое количество систем для их автоматизации - от небольших

узконаправленных систем (1С-бухгалтерия, БОСС-Кадровик и др.), до комплексных

систем класса ERP (SAP/R3, Oracle Applications и др.).

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

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

Автоматизируя бизнес-процессы по отдельности, не принимая во внимание интересы

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

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

процесс автоматизации и вести к неоправданно значительным затратам. Только

объединив компоненты в единое целое, можно получить систему, обладающую

свойствами КИС, и действительно полезную организации.

Методы и средства проектирования КИС

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

Важнейшими являются структурный и объектно-ориентированный методы, которые,

однако, не стоит противопоставлять - каждый из них на различных этапах анализа и

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

Структурный метод

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

Основным строительным блоком является процедура или функция, а внимание

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

алгоритмов на меньшие. Но, к сожалению, системы не слишком легко адаптируются.

При изменении требований или увеличении размера приложения (что происходит

нередко) сопровождать их становится сложнее. Однако структурный метод является

чрезвычайно удобным на этапе анализа и проектирования - поскольку аналитики

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

функций.

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

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

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

Объектно-ориентированный метод

Является наиболее современным методом разработки программного

обеспечения. Здесь в качестве основного строительного блока выступает объект или

класс. В самом общем смысле объект - это сущность, обычно извлекаемая из словаря

предметной области или решения, а класс является описанием множества

однотипных объектов. Каждый объект обладает идентичностью (его можно

поименовать или как-то по-другому отличить от прочих объектов), состоянием

(обычно с объектом бывают связаны некоторые данные) и поведением (с ним можно

что-то делать или он сам может что-то делать с другими объектами).

Объектно-ориентированный метод разработки программного обеспечения

является преобладающим сейчас по той причине, что он продемонстрировал свою

полезность при построении систем в самых разных предметных областях и для

различных уровней сложности и масштаба. Кроме того, большинство современных

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

являются в той или иной мере объектно-ориентированными, а это дает веские

основания судить о мире в терминах объектов.

Применение методов и средств проектирования КИС

Поскольку в построении модели предметной области кроме аналитиков на начальной

стадии принимают участие эксперты предметной области (рис. 5), к применяемым

моделям выдвигаются следующие требования:

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

предметной области, которые не имеют специальной подготовки аналитиков;

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

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

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

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

В настоящее время экспертам предметной области наиболее доступны к пониманию

структурные модели бизнес-процессов. Однако, наиболее понятным, несомненно,