В настоящее время существует множество подходов или стандартов описания бизнес-процессов. Однако на самом деле классическая технология их описания состоит всего лишь из двух стандартов — DFD (DataFlowDia-gram) и WFD(WorkFlowDiagram). Первый представляет собой диаграмму потоков данных, которая используется для описания бизнес-процессов верхнего уровня; второй — диаграмму потоков работ, которая используется для описания бизнес-процессов нижнего уровня. Большинство других современных стандартов представляют разновидности и дополнения двух классических подходов.
Построение диаграмм потоков данных (DFD)
На диаграмме потоков данных показываются работы, которые входят в состав описываемого бизнес-процесса, а также показываются входы и выходы каждой из работ. Данные входы и выходы представляют собой информационные, либо материальные потоки. При этом выходы одной работы могут являться входами для других.
Входы и выходы, которые были показаны при описании окружения бизнес-процесса, являются внешними. Внешние входы на DFD-схеме поступают извне от поставщика процесса, а внешние выходы уходят наружу к клиенту процесса. При построении DFD-схемы бизнес-процесса их нужно перенести со схемы окружения процесса DFD-диаграмму.
Создание финансовой модели за 10 минут с нуля
Для окончательного описания бизнес-процесса остается описать только внутренние информационные и материальные потоки. Каждый из них является выходом одной из работ и в то же является входом для другой (рис. 4.9).
Первичный вход А
Код:А1 Название: Действие_1 + 0бъект_1
Источник: bstudy.net
Динамическое моделирование бизнес-процессов
В настоящее время любое предприятие стремится к максимальной эффективности своей деятельности, а это невозможно без внедрения современных информационных технологий (ИТ). В свою очередь, управление инновационными проектами влечет за собой необходимость перехода на новые методы управления.
Современный подход к управлению предполагает прежде всего стратегический и тактический анализ функционирования предприятия для получения представления руководства предприятия о нынешнем состоянии бизнеса и моделирования его дальнейшего развития. С помощью инструментальных средств моделирования задачи управления и оптимизации бизнес-процессов на предприятии решаются быстро и эффективно, создается бизнес-модель действующего предприятия, анализируются взаимосвязи наиболее важных компонентов модели и определяются возможности их преобразования. Указанный автоматизированный процесс построения бизнес-модели предприятий автоматически генерирует систему требуемой функциональности. Результат этого процесса — «интегрированная модель предприятия», способная оперативно развиваться в процессе деятельности предприятия и гибко адаптироваться к изменениям условий деятельности.
Концепция динамического моделирования предприятия (DEM) основана на определении характерных бизнес-моделей для некоторых типов организаций, так называемых референтных моделей предприятия. Они используются в процессе создания системы управления инновационными проектами и при реинжиниринге бизнес-процессов. Для создания и внедрения референтных моделей DEM использует средства моделирования, и в процессе реализации выбранные референтные модели адаптируются к специфическим требованиям предприятия.
Такая методология внедрения обеспечивает графические средства и модели образцов наилучшей практики, которые позволяют пользователям вводить новые бизнес-процессы, не беспокоясь о технической стороне дела. Пользователи также могут быстро сконфигурировать бизнес-модель и в рабочем режиме модифицировать бизнес-процессы. Изменения бизнес-процесса осуществляются параллельно с уже действующей моделью.
Средства моделирования предприятия — инструментальные средства, предоставляющие возможность определения и графического изображения бизнес-функций, бизнес-процессов, организационной структуры предприятия и их взаимодействия друг с другом.
С использованием компонента Средства моделирования можно создавать бизнес-модели предприятия. Бизнес-модель предприятия состоит из модели бизнес-функций, модели бизнес-процессов и организационной модели (рис. 7.5).
Бизнес-модель предприятия может содержать два уровня. Первый уровень — модель бизнес-функций, которая определяется в общепринятых терминах. Бизнес-функции представляют собой цели и задачи предприятия. Они описывают, не вдаваясь в детали, что должно быть сделано, как это будет сделано.
Второй уровень — модель бизнес-процессов. Бизнес-процессы определяют, как должны выполняться бизнес-функции путем определения требуемых процессов и работ. Модель бизнес-процессов генерируется из предварительно определенной модели бизнес-функций. Это означает, что можно преобразовывать общие бизнес-модели в модели, специфичные для отдельного инновационного проекта.
Модель бизнес-процессов может использоваться руководителями для получения представления о текущем состоянии дел и аппроксимации вероятных отклонений. В результате потенциальные проблемы могут быть выявлены на ранних стадиях.
Рис. 7.5. Структура бизнес-модели предприятия
Полнота моделей бизнес-функций и бизнес-процессов может проверяться с помощью правил. Правила также используются для преобразования модели бизнес-функций в модель бизнес-процессов. Кроме того, правила применяются для установки параметров референтных моделей проектов — бизнес-правила, горизонтальные и вертикальные связи.
Эти модели позволяют предприятиям начать разработку собственных моделей на основе уже готового набора функций и процессов.
Таким образом, благодаря динамическому моделированию бизнес-процессов появляется возможность использования бизнес-моделей проектов, разработанных для конкретной отрасли промышленности, учитывающих опыт внедрения на предприятиях данной конкретной отрасли и включающих проверенные на практике процедуры и методы организации бизнеса. Помимо испытанных бизнес-процессов динамичные модели также включают рекомендуемые пути улучшения различных бизнес-функций и показателей деятельности, способствующие усовершенствованию бизнеса.
Основными преимуществами динамического моделирования бизнес-процессов при управлении инновационными проектами являются:
- • Бизнес-модели для проектов конкретной отрасли промышленности, включающие проверенные на практике бизнес-процедуры и методы.
- • «Ноу-хау» в области усовершенствования инновационной и хозяйственной деятельности, например пути оптимизации бизнес-функций, бизнес-процессов и показателей деятельности.
- • Эффективная отправная точка для преобразования бизнес-целей и приоритетов в модель бизнес-процессов инновационного проекта при принятии его к выполнению и контролю по контрольным точкам, характерным только для данного конкретного проекта.
В условиях рыночной экономики качество информационной поддержки деятельности руководителей и аналитиков становится одним из факторов достижения предприятиями конкурентных преимуществ. Такую поддержку невозможно осуществить непосредственно на основе данных OLTP (On-Line Transaction Processing)—технологий, автоматизирующих сбор и первичную обработку данных о деятельности предприятия. Именно это и обусловило интерес к системам поддержки принятия решений (СППР), которые являются основной сферой применения О LAP (On-Line Analytical Processing — оперативная аналитическая обработка, оперативный анализ данных), превращающей «руду» OLTP-систем в готовое «изделие», которое руководители и аналитики могут непосредственно использовать.
В той или иной степени СППР присутствуют в любой информационной системе. По мере развития бизнеса, упорядочения структуры организации и налаживания межкорпоративных связей проблема разработки и внедрения СППР становится особенно актуальной. Основным подходом к созданию таких систем стало использование хранилищ данных. Ниже представлены некоторые этапы и методики проведения подобных работ на опыте и с применением методологии компании Price Waterhouse, которая выполнила более 40 крупномасштабных проектов на базе данной технологии разработки модели и внедрения бизнес-процессов управления.
Первая фаза проекта — бизнес-анализ процессов и данных предприятия и разработки хранилища данных (ХД). В России, несмотря на широкое распространение кейс-технологии, к бизнес-анализу и проектированию данных на концептуальном уровне не всегда относятся достаточно серьезно. Между тем относительно СППР на основе ХД можно с уверенностью утверждать, что ее разработка без подобного анализа заранее обречена на неудачу. Без ясного понимания разработчиками целей бизнеса, способов их достижения, возникающих при этом проблем и методов их решения ресурсы, необходимые для разработки ХД, будут потрачены зря. Самым критичным из ресурсов сейчас является время, и тот, кто начал разработку СППР, не определив заранее, кто, когда, зачем и как будет принимать решения, какое влияние то или иное решение оказывает на бизнес, какие решения отнести к оперативным, а какие к стратегическим и т. д., обрекает себя на неизбежное отставание в конкурентной борьбе.
Идея Витрины Данных (Data Mart) возникла в конце XX в., когда стало очевидно, что разработка корпоративного хранилища — долгий и дорогостоящий процесс. Это обусловлено как организационными, так и техническими причинами:
- • информационная структура реальной компании, как правило, очень сложна, и руководство зачастую плохо понимает суть происходящих в компании бизнес-процессов;
- • технология принятия решений ориентирована на существующие технические возможности и с трудом поддается изменениям;
- • может возникнуть необходимость в частичном изменении организационной структуры компании;
- • требуются значительные инвестиции до того, как проект начнет окупаться;
- • как правило, требуется значительная модификация существующей технической базы;
- • освоение новых технологий и программных продуктов специалистами компании может потребовать много времени;
- • на этапе разработки бывает трудно наладить взаимодействие между разработчиками и будущими пользователями хранилища.
В совокупности это приводит к тому, что разработка и внедрение корпоративного хранилища требуют значительных усилий по анализу деятельности компании и переориентации ее на новые технологии. Витрины Данных возникли в результате попыток смягчить трудности разработки и внедрения хранилищ.
Сейчас под Витриной Данных понимается специализированное хранилище, обслуживающее одно из направлений деятельности компании, например учет запасов или маркетинг. Важно, что происходящие здесь бизнес-процессы, во-первых, относительно изучены и, во-вторых, не столь сложны, как процессы в масштабах всей компании. Количество сотрудников, вовлеченных в конкретную деятельность, также невелико (рекомендуется, чтобы Витрина Данных обслуживала не более 10—15 человек). При этих условиях удается с использованием современных технологий развернуть Витрину подразделения за 3—4 месяца. Необходимо отметить, что успех небольшого проекта (стоимость которого невелика по сравнению со стоимостью разработки корпоративного хранилища), во-первых, способствует продвижению новой технологии и, во-вторых, приводит к быстрой окупаемости затрат.
Первые же попытки внедрения Витрин Данных оказались настолько успешными, что вокруг новой технологии начался настоящий бум. Предлагалось вообще отказаться от реализации корпоративного хранилища и заменить его совокупностью Витрин Данных. Однако вскоре выяснилось, что с ростом числа Витрин растет сложность их взаимодействия, поскольку сделать Витрины полностью независимыми не удается. Сейчас принята точка зрения, в соответствии с которой разработка корпоративного хранилища должна идти параллельно с разработкой и внедрением Витрин Данных.
При построении схемы взаимодействия корпоративного хранилища и Витрин Данных в рамках создания СП ПР рекомендуется определить некоторую специальную структуру для хранения исторических данных и дополнительно развернуть ряд Витрин, заполняемых данными из этой структуры. Тем самым удается разделить два процесса: накопление исторических данных и их анализ.
В самом простом варианте для ХД используется та модель данных, которая лежит в основе транзакционной системы. Если, как это часто бывает, транзакционная система функционирует на реляционной СУБД (Oracle, Informix, Sybase и т.п.), самой сложной задачей становится выполнение запросов ad-hoc, поскольку невозможно заранее оптимизировать структуру базы данных так, чтобы все запросы работали эффективно.
Однако практика принятия решений показала, что существует зависимость между частотой запросов и степенью агрегированно- сти данных, с которыми запросы оперируют, а именно, чем более агрегированными являются данные, тем чаще запрос выполняется. Другими словами, круг пользователей, работающих с обобщенными данными, шире, чем тот, для которого нужны детальные данные. Это наблюдение легло в основу подхода к поиску и выборке данных, называемого Оперативной Аналитической Обработкой (On-line Analytical Processing, OLAP). OLAP-системы построены на двух базовых принципах:
- • все данные, необходимые для принятия решений, предварительно агрегированы на всех соответствующих уровнях и организованы так, чтобы обеспечить максимально быстрый доступ к ним;
- • язык манипулирования данными основан на использовании бизнес-понятий.
В основе О LAP лежит понятие гиперкуба, или многомерного куба данных, в ячейках которого хранятся анализируемые (числовые) данные, например объемы продаж. Измерения представляют собой совокупности значений других данных, скажем названий товаров и названий месяцев года. В простейшем случае двумерного куба (квадрата) мы получаем таблицу, показывающую значения уровней продаж по товарам и месяцам. Дальнейшее усложнение модели данных может идти по нескольким направлениям:
- • увеличение числа измерений — данные о продажах не только по месяцам и товарам, но и по регионам; в этом случае куб становится трехмерным;
- • усложнение содержимого ячейки — например, нас может интересовать не только уровень продаж, но и, скажем, чистая прибыль или остаток на складе; в этом случае в ячейке будет несколько значений;
- • введение иерархии в пределах одного измерения — общее понятие, время, естественным образом связано с иерархией значений: год состоит из кварталов, квартал из месяцев и т. д.
Имеется в виду не физическая структура хранения, а лишь логическое построение данных. Другими словами, определяется лишь пользовательский интерфейс модели данных. В рамках этого интерфейса вводятся следующие базовые операции:
- • поворот;
- • проекция; при проекции значения в ячейках, лежащих на оси проекции, суммируются по некоторому предопределенному закону;
- • раскрытие (drill-down); одно из значений измерения заменяется совокупностью значений из следующего уровня иерархии измерения; соответственно заменяются значения в ячейках гиперкуба;
- • свертка (roll-up/drill-up); это операция, обратная раскрытию;
- • сечение (slice-and-dice).
В зависимости от ответа на вопрос, существует ли гиперкуб как отдельная физическая структура или лишь как виртуальная модель данных, различают системы MOLAP (Multidimensional OLAP) и ROLAP (Relational OLAP). В первых гиперкуб реализуется как отдельная база данных специальной нереляционной структуры, обеспечивающая максимально эффективный по скорости доступ к данным, но требующая дополнительного ресурса памяти. MOLAP-системы весьма чувствительны к объемам хранимых данных. Поэтому данные из хранилища сначала помещаются в специальную многомерную базу (Multidimensional Data Base, MDB), а затем эффективно обрабатываются OLAP-сервером.
Одним из первых производителей таких систем стала компания Arbor Software, выпустившая продукт Essbase. Компания Oracle предлагает систему Oracle Express, интегрированную с универсальным Oracle Server. Известны и другие производители MOLAP-систем, например SAS Institute. Однако, в отличие от Essbase, их продукты часто интегрированы в приложения, созданные для конкретных вертикальных или горизонтальных рынков, и поставляются лишь в составе этих приложений.
Для систем ROLAP гиперкуб — это лишь пользовательский интерфейс, который эмулируется на обычной реляционной СУБД. В этой структуре можно хранить очень большие объемы данных, однако ее недостаток заключается в низкой и неодинаковой эффективности OLAP-операций.
Опыт эксплуатации ROLAP-продуктов показал, что они больше подходят на роль интеллектуальных генераторов отчетов, чем действительно оперативных средств анализа. Они применяются в таких областях, как розничная торговля, телекоммуникации, финансы, где количество данных велико, а высокой эффективности запросов не требуется. Примерами промышленных ROLAP-систем служат MetaCube фирмы Informix и Discoverer 3.0 фирмы Oracle. На практике иногда реализуется комбинация этих подходов.
Некоторые поставщики программных продуктов (Sybase — Sybase IQ, Teradata) поставляют более сложные решения, основанные на специальных методах хранения и индексации данных и связей между данными.
При определении программно-технологической архитектуры ХД следует иметь в виду, что система принятия решения, на какие бы визуальные средства представления она ни опиралась, должна предоставить пользователю возможность детализации информации. Руководитель предприятия, получив интегрированное представление данных и/или выводы, сделанные на его основе, может затребовать более детальные сведения, уточняющие источник данных или причины выводов. С точки зрения проектировщика СП ПР, это означает, что необходимо обеспечить взаимодействие СППР не только с ХД, но и в некоторых случаях с транзакционной системой.
Таким образом, основное назначение модели инновационного проекта — определение и формализация данных, действительно необходимых в процессе принятия решения в условиях повышенной неопределенности. Известно два подхода к бизнес-планированию. Первый ориентируется на описание бизнес-процессов, соответствующих проекту, которые моделируются набором взаимосвязанных функциональных элементов. Поскольку эти процессы, как правило, хорошо известны, на первый взгляд кажется, что это самый естественный и быстрый путь бизнес-анализа. Действительно, если бизнес стабилен и внешние факторы не играют в нем решающей роли либо также стабильны, этот путь может оказаться наиболее эффективным, но не в случае инновационных решений.
При проектировании модели управления инновационными проектами предприятия подход, основанный на первичном анализе бизнес-событий, обеспечивает наибольшую эффективность:
- • позволяет гибко модифицировать бизнес-процессы, ставя их в зависимость от бизнес-событий;
- • интегрирует данные, которые при анализе бизнес-процессов остаются скрытыми в алгоритмах обработки данных;
- • объединяет управляющие и информационные потоки;
- • наглядно показывает, какая именно информация нужна при обработке бизнес-события и в каком виде она представляется.
Иными словами, бизнес-событие является более устойчивым и более тесно связанным с информационными и управляющими потоками понятием, чем бизнес-процесс.
Источник: studref.com
Отличительными чертами концепции бизнес моделирования являются сочетание динамического
Связь методик и инструментов совершенствования деятельности предприятия реализуется на трех уровнях:
1. Концептуальное моделирование — для определения направления развития предприятия.
2. Логическое моделирование — для описания деятельности предприятия CASE-средствами.
3. Физическое моделирование — для формализации деятельности предприятия средствами ERP-системы (то есть для создания нормативной модели предприятия).
Концептуальная модель является отраслевой моделью и, как правило, разрабатывается для предприятия внешним консультантом (обычно на основе эталонных моделей, предлагаемых поставщиками ERP-систем). В ней определяются основные направления развития предприятия через графическое представление передовой мировой практики (заключенной в стандарты ISO и ERP) и через определение несоответствий деятельности предприятия данной практике (на основе проведения сопоставительного анализа). Концептуальная модель подразумевает унификацию основных процессов предприятия в соответствии со стандартами ISO 9001:2000 и ERP.
На (рис. 4) представлен верхний уровень эталонной модели, предложенной фирмой QAD (США) для предприятий, ориентированных на внедрение ERP-системы MFG/PRO. Данная модель базируется на ERP-стандартах.
Эталонная модель с использованием ISO 9000 переводится в IDEF0-модель (рис. 5). Таким образом, мы получаем концептуальную модель предприятия, где осуществляются:
· декомпозиция процессов предприятия — верхний уровень иерархии процессов соответствует элементам и подэлементам стандарта ISO 9001:2000, а нижние уровни раскрываются с использованием ERP-стандарта;
· проектирование графического «скелета» документации СМК предприятия;
· определение ключевых пользователей процессов и бизнес-функций;
· определение на базе ERP-системы основных модулей информационной системы предприятия, обеспечивающих выполнение процессов;
· определение связей процессов по входам/выходам.
IDEF0-модель позволяет построить статическую модель деятельности предприятия. Однако, по мнению специалистов, данная методика моделирования имеет ограничения, которые не позволяют эффективно осуществлять стыковку отдельных операций, то есть описывать рабочие потоки. Построение динамической модели предприятия осуществляется на следующем уровне бизнес-моделирования (логическом), а декомпозиция процессов в IDEF0-модели используется для определения функционального аспекта предприятия в логической модели [4, с 5-6].
Сущность бизнес-модели (логическая модель)
Второй уровень бизнес-моделирования — логический — необходим для уточнения основных выводов, следующих из концептуальной модели. Логическая модель описывает деятельность предприятия, посредством объектно-ориентированного проектирования (опираясь на методологию бизнес-моделирования RUP9 и нотации UML10). Цель логического моделирования — построить интегрированную модель деятельности предприятия, являющейся связующим звеном между бизнес-методиками и ERP-системой. Логическая модель позволяет спланировать, как нужно реорганизовать текущие способы выполнения процессов предприятия в желаемые — вплоть до каждого рабочего места. Данная реорганизация закрепляется с помощью регламентирующей документации СМК, сгенерированной из логической модели.
Исходя из требований перехода предприятия на следующий уровень BPI логическая модель помогает детально ответить на следующие вопросы:
· кто и где исполняет бизнес-функции (организационный аспект деятельности);
· что перемещается в материальных и в связанных с ними информационных потоках (элементный аспект деятельности предприятия);
· как предприятие выполняет бизнес-функции (функциональный аспект);
· когда предприятие осуществляет бизнес-функции (динамический аспект);
· какая информационная платформа (какие инструменты) необходима для поддержания бизнес-функций на предприятии.
На (рис. 6) представлено взаимодействие функционального, организационного, элементного, динамического аспектов логической модели и приведены примеры наиболее часто используемых диаграмм (диаграммы пакетов, прецедентов, классов, деятельности).
В рамках функционального аспекта описываются:
· иерархическая структура процессов;
· взаимодействие процессов (реализация процессного подхода).
Процессы на предприятии определяются наличием конечного продукта (не обязательно материального), у которого есть потребитель и поставщик. Отношения «поставщик — потребитель» рассматриваются не только с внешними контрагентами, но и внутри предприятия. Для описания процессов предлагается использовать диаграммы пакетов — универсальный механизм в UML для организации элементов в группы.
Выделение процессов осуществляется с привлечением концептуальной модели. Здесь организуется следующая иерархия процессов: элементы стандарта ISO 9001:2000 — 1-й уровень иерархии пакетов; подэлементы ISO — 2-й и 3-й уровни иерархии пакетов; унифицированные бизнес-процессы (описанные ERP-стандартом) — 4-й и 5-й уровни иерархии пакетов. Для каждого процесса (пакета в модели) описываются его цели и критерии достижения этих целей. Детальная стыковка процессов определяется через взаимодействие способов их выполнения в отдельной папке, именуемой «Сценарии».
В рамках организационного аспекта описываются:
· организационная структура предприятия, включающая в себя иерархию подразделений, отделов, участков, должностей, рабочих мест;
· топология предприятия: местоположения хранения складских запасов, рабочие центры выполнения операций, поточные линии.
Для описания топологии и оргструктуры предприятия предлагается использовать диаграммы прецедентов, где отражается иерархия подчинения действующих лиц и организационных единиц.
В рамках элементного аспекта описываются единицы материального, информационного и финансового потоков (единицы документооборота, товарооборота и финансовые инструменты) для каждого процесса предприятия.
Составляющие элементного аспекта используются при описании текущих и желаемых способов выполнения процессов. Взаимодействие объектов (или документооборот для информационных объектов) одного и того же процесса зависит от конкретной ситуации и конкретного способа выполнения этого процесса.
Для описания элементного аспекта предприятия предлагается использовать диаграмму классов, а для отражения возможных состояний элементов — диаграмму состояний.
В рамках динамического аспекта реализуется ситуационный подход:
· определяются способы выполнения процесса в зависимости от конкретной ситуации, поскольку, как известно, процесс может быть реализован разными последовательностями действий. Процесс может выполняться несколькими способами, и выбор способа определяется конкретной ситуацией с привлечением того или иного ответственного лица. Описание каждого процесса включает диаграмму прецедентов (в трактовке диаграммы бизнес-сценариев), описывающую способы выполнения процессов и определяющую ответственных лиц, участвующих в выполняемых действиях. Для описания взаимодействия процессов (в специальной папке «Сценарии») также используются диаграммы сценариев (прецедентов), где кроме описания способов отражаются информационные и материальные объекты, являющиеся результатом выполнения процесса или использующиеся для его инициализации;
· определяются взаимодействия организационного, элементного и функционального аспектов, то есть раскрывается способ выполнения процесса. Для этого предлагается использовать диаграммы деятельности, где отражается взаимосвязь процессов на предприятии с ERP-системой. (При описании действия указывается режим в ERP-системе, обеспечивающий выполнение данного действия.);
· определяется документооборот (или товарооборот) между организационными единицами. Документооборот описывается для каждого способа выполнения процесса. Для описания взаимодействия документов и исполнителей предлагается использовать диаграммы кооперации.
Законченная логическая модель является базой данных для генерации методических и должностных инструкций в формате ISO 9001:2000 с помощью генератора отчетов Rational SoDA (рис. 7). Шаблон для логической модели создается на базе стандарта ISO 9001:2000, поэтому имеется возможность генерации из данной модели документации СМК 2-го и 3-го уровней.
С помощью логической модели можно управлять реорганизацией процессов предприятия на основе синхронизированной работы ERP-системы и СМК. Модель позволяет предприятию более гибко подходить к изменениям в документации СМК и разрабатывать минимальное количество документов. В дальнейшем предприятие может использовать логическую модель для организации бизнес-портала, основная часть которого также генерируется из логической модели, и разместить его в Интранете или Интернете, предоставляя своему персоналу оперативный доступ к корпоративным знаниям. Для поддержания логической модели в актуальном состоянии необходимо, чтобы все задачи изменения способов выполнения процессов на предприятии решались с помощью существующей модели.
В целях облегчения и ускорения процесса моделирования предлагается применять шаблон модели предприятия, созданный внешним консультантом. Использование шаблона обеспечивает интеграцию созданной модели и ERP-системы (внедряемой на предприятии), что гарантирует, во-первых, слаженную работу бизнес-аналитика и аналитика ИС, во-вторых, сокращение сроков разработки модели предприятия, а в-третьих, получение запланированного эффекта от моделирования и внедрения ERP-системы.
Необходимо еще раз подчеркнуть, что в логической модели проектируются только те желаемые способы выполнения процессов, которые необходимы для перехода предприятия на вышестоящий уровень BPI. Например, если предприятие находится на уровне BPI «Хаос», то в логической модели будут отражаться способы организации деятельности предприятия по стандартам MRPII. Здесь мы пока не будем касаться методик, связанных с JIT или CSRP (хотя данные методики ведения бизнеса поддерживаются ERP-системой MFG/PRO), поскольку считаем, что совершенствование должно идти поэтапно и что предприятие не может «прыгнуть выше головы» [4, с 9-19].
Источник: studbooks.net
