Интеллектуальные информационные системы управления предприятием - читать онлайн

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

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

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

Рассмотрение данного вопроса следовало бы начать собственно с определения того, а чем же является интеллектуальное предприятие. На сегодня не существует устоявшегося и общепризнанного определения того, что же является интеллектуальным предприятием. Предприятие – самостоятельный, организационно-обособленный хозяйствующий субъект с правами юридического лица, который производит и сбывает товары, выполняет работы, оказывает услуги [1–3]. В современных условиях предприятие является основным звеном рыночной экономики, поскольку именно на этом уровне создаются нужные обществу товары, оказываются необходимые услуги. Предприятие как юридическое лицо имеет право заниматься любой хозяйственной деятельностью, не запрещенной законодательством и отвечающей целям создания предприятия, предусмотренным в уставе предприятия. Предприятие имеет самостоятельный баланс, расчетный и иные счета в банках, печать со своим наименованием [2,3].

Искусственный интеллект (ИИ; англ. artificial intelligence, AI) – наука и технология создания интеллектуальных машин, особенно интеллектуальных компьютерных программ [4]. Свойство интеллектуальных систем – выполнять творческие функции, которые традиционно считаются прерогативой человека [5]. ИИ связан со сходной задачей использования компьютеров для понимания человеческого интеллекта, но не обязательно ограничивается биологически правдоподобными методами [4]. Существующие на сегодня интеллектуальные системы имеют очень узкие области применения. Например, программы, способные обыграть человека в шахматы, не могут отвечать на вопросы и т. д. [6]. Возможность формирования идеи интеллектуального предприятия появилась во многом благодаря развитию информационных технологий (ИТ, также – информационно-коммуникационные технологии [7,8]), под которыми понимаются процессы, методы поиска, сбора, хранения, обработки, предоставления, распространения информации и способы осуществления таких процессов и методов (ФЗ № 149-ФЗ) [9]; приёмы, способы и методы применения средств вычислительной техники при выполнении функций сбора, хранения, обработки, передачи и использования данных (ГОСТ 34.003-90) [10]; ресурсы, необходимые для сбора, обработки, хранения и распространения информации (ISO/IEC 38500:2008). Исходя из предложенных определений, очевидно, что под интеллектуальным предприятием понимается некое промышленном предприятие (завод), которое управляется искусственным интеллектом и возможно полностью обходится без людей.

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

При этом мы понимаем, что до такого будущего вроде бы еще далеко, но ведь уже сегодня существуют заводы, на которых до 90 % всех работ выполняют роботы; станки с ЧПУ за одну установку выполняют обработку детали, которую ранее осуществляли десятки людей; автоматические системы складского хранения полностью автоматически управляют работой склада; беспилотные автомобили вот-вот появятся на улицах крупных городов. И эта тенденция с каждым днем прослеживается все сильнее. И тут, конечно, нельзя не задать себе еще один вопрос – а чем будут заняты люди, которые ранее трудились в тех сферах деятельности, которые теперь переданы в компетенцию искусственного интеллекта? На этот вопрос на сегодня ответа нет и это обстоятельство очень настораживает. Здесь следует задать и еще один вопрос – а зачем человечество с такой скоростью движется к тому, чтобы передать все компетенции искусственному интеллекту? А ответ крайне прост – те операции, которые подлежат к передаче в область ведения искусственного интеллекта, как правило, выполняются в сотни раз эффективнее, быстрее, с меньшим количеством ошибок, круглосуточно и без выходных. Как правило, это приводит к существенному росту производительности и эффективности предприятия, что увеличивает прибыль предприятия и создает возможность для дальнейшего развития, а далее цикл повторятся снова и снова.

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

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

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

1.2.1 Основные признаки интеллектуального предприятия

В современных условиях быстроменяющейся конъюнктуры рынков сбыта, труда, технологий и инноваций эффективное управление промышленным предприятием становится все более сложной проблемой. В новом технологическом укладе резко возрастает роль информационных технологий, связанных с развитием глобальных информационных систем, искусственного интеллекта и интегрированных высокоскоростных систем коммуникаций. Информационное общество испытывает постоянный дефицит полезной информации, необходимой для принятия правильных решений. Это в полной мере относится и к промышленному предприятию, успешное функционирование и развитие которого напрямую связано с использованием новых моделей организации производства и специальных механизмов управления эволюцией предприятия. Как утверждают авторы [11], наиболее эффективно овладевает капиталом предприятие, обеспечивающее самоорганизацию, а также обучение и адаптацию его работников в условиях быстрых изменений. В рамках этой концепции предприятие рассматривается как развивающаяся система, в основе которой лежит самоорганизация. При этом такая система обычно имеет иерархическую структуру, так или иначе упорядоченную на каждом из уровней иерархии. Управление большой и сложной производственной системой предусматривает постоянное и интенсивное взаимодействие с внешним миром, в том числе информационный обмен. Такие системы принято называть открытыми, в которых при определенных условиях возможны процессы самоорганизации, т. е. возникновение устойчивых состояний организованности и поддержания порядка в системе. В качестве меры упорядоченности часто используют энтропию. Поэтому логично управлять упорядоченностью системы путем снижения или повышения ее энтропии в зависимости от стратегических целей предприятия [12]. Другими словами, необходимо создавать условия для самоорганизации системы и обоснованно ожидать появления новых структур, приводящих к новому устойчивому состоянию. Для повышения организованности сложной производственной системы необходимо оказать на нее дополнительное внешнее воздействие, т. е. увеличить степень открытости, которой будет соответствовать новый, более высокий уровень организации системы. Однако, размыкая систему с целью ее самоорганизации, необходимо обосновать возможную степень ее синергетической открытости, т. к. превышение допустимого порога может привести к тому, что система, не успев самоорганизоваться, разрушится [13,14].

Кроме обеспечения самоорганизации с целью своего развития предприятие должно непрерывно использовать обучение и адаптацию, для чего необходим интеллект. Поэтому в [11] дается следующее определение: «Интеллектуальное предприятие – это самоорганизация, обучение и адаптация». Это определение подразумевает, что способность к самоорганизации органически присуща предприятию как развивающейся системе, а способность к обучению и адаптации – интеллекту. При этом интеллектуальное предприятие реализует процессы обучения и адаптации с помощью «спиралей прогресса», которые представляют собой восходящие последовательности циклов «исследование-производство». Каждый цикл повышает эффективность производства и качество выпускаемой продукции за счет внедрения новых технологий и выпуска новых продуктов, т. е. инноваций. Поэтому первым важным признаком интеллектуальности предприятия является количество контролируемых им «спиралей прогресса», с помощью которых постоянно решаются задачи овладения капиталом в изменяющихся условиях. Для реализации циклов «исследование-производство» структура предприятия должна включать научно-исследовательское подразделение, специальное конструкторское бюро и опытное производство. Поддержание «спирали прогресса» в долгосрочной перспективе невозможно без эффективного стимулирования инновационных процессов, протекающих в развивающейся системе. Предприятие должно не только создавать новые продукты и технологии, но и быстро осваивать их в производстве, а также продвигать их на внутреннем и мировом рынке. Для этого интеллектуальное предприятие должно активно участвовать в кооперации и интеграции с наукой и образованием. Тесное сотрудничество с научно-исследовательскими институтами и университетами позволит поддерживать экономический рост и конкурентоспособность предприятия на мировых рынках [15].

Вторым важным признаком интеллектуального предприятия является применение эффективных механизмов управления руководителями этого предприятия в практике своей деятельности, которые могут быть названы механизмами умного управления [16–18]. Под умным управлением понимается способность умных руководителей применять умные методы и механизмы в своей производственной деятельности [16]. По мнению авторов монографии [16], к умным методам управления можно отнести:

1. Стратегические методы формирования приоритетов на определенный период времени.

2. Методы всестороннего анализа динамики показателей работы промышленных предприятий.

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

4. Методы совершенствования производственной логистики.

5. Методы и технологии оценки внешних по отношению к предприятию факторов.

6. Методы формирования современной структуры компании с ее ориентацией на повышение гибкости управления персоналом.

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

Кроме умных методов на интеллектуальном предприятии, должны активно применяться умные механизмы с охватом полного цикла управления, которые можно условно разбить на 4 группы [16]:

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

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

3. Советующие механизмы, позволяющие продуцировать рекомендации лицу, принимающему решения. Это могут быть компьютерные экспертные системы или группы экспертов, использующие современные механизмы коллективного принятия решений [19]. Для реализации этих механизмов на интеллектуальном предприятии целесообразно создавать специальные ситуационные центры, позволяющие быстро реагировать на возникающие производственные ситуации и осуществлять выбор наилучшего управленческого решения [20].

4. Развивающие механизмы, стимулирующие развитие промышленного предприятия (снижение издержек, внедрение инноваций и т. д.). С одной стороны, «противозатратные механизмы» предназначены для борьбы с монополистом. Такие механизмы были разработаны в рамках теории активных систем [21], основная идея которых заключалась в том, что норматив рентабельности был поставлен в зависимость от себестоимости, т. е. с уменьшением себестоимости норматив увеличивался, но так, что цена продукции при этом уменьшалась. С другой стороны, к снижению затрат предприятия приводят и другие механизмы управления, например, механизмы бережливого производства, которые будут рассмотрены в разделе 2.1 настоящей книги.

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

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

На втором этапе, когда предприятие работает стабильно и сформированы стратегические цели, появляется возможность для улучшений за счет повышения эффективности управления производством путем внедрения различных передовых технологий, к которым можно отнести Lean Production (бережливое производство), JIT (точно в срок), QRM (быстрореагирующее производство) и другие. Большинство известных технологий управления будут рассмотрены во второй главе книги. На этом этапе автоматизация охватывает практически все основные и поддерживающие бизнес-процессы путем разработки и внедрения различных информационных ERP-систем для планирования производства и управления ресурсами предприятия [24]. Следует отметить, что большинство современных отечественных промышленных предприятий в настоящее время находятся на втором этапе своего организационного развития и активно внедряют информационные системы в производство с различной степенью успешности. Это связано с тем, что отсутствуют отечественные общепризнанные ERP-системы, удовлетворяющие требования потребителей по важным критериям эффективности [25], а зарубежные ERP-системы дороги и требуют дополнительной подготовки специалистов по их сопровождению.

На третьем этапе организационного развития, которое соответствует интеллектуальному предприятию, появляется необходимость управления не только данными, но и знаниями, для создания уникальных продуктов и услуг, выходящих за рамки знаний и опыта отдельных руководителей и экспертов [26]. Целью этого этапа является перевод знаний от отдельных индивидов к организации. В результате повышается устойчивость предприятия в настоящем и создаются предпосылки для качественного преобразования предприятия в будущем. Для реализации новых бизнес-процессов управления создаются корпоративные порталы, экспертные системы для анализа бизнеса [27], включая средства многомерного и интеллектуального анализа данных [28], генераторы запросов и отчетов, средства имитационного моделирования производства [29] и цифровые двойники предприятия [30]. На данном этапе резко изменяется роль информационной системы предприятия. Она не только автоматизирует существующие бизнес-процессы, но и позволяет создавать новые, до этого принципиально невозможные. И наконец, в наиболее развитом состоянии информационная система, основанная на знаниях, может сама предлагать новые бизнес-процессы, изменяя предприятию бизнес-фокус или даже создавая абсолютно новый бизнес, построенный на инновациях. Тем самым информационная система активно участвует в самоорганизации предприятия, подсказывая руководству наиболее эффективные пути развития, а также берет на себя важную роль в адаптации и обучении персонала, передавая накопленные знания. Это, в свою очередь, обеспечивает поддержание «спирали прогресса» в долгосрочной перспективе и делает предприятие действительно интеллектуальным.

1.2.1 Уровни управления

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

На стратегическом уровне [31] происходит разработка и реализация действий, ведущих к долгосрочному превышению уровня результативности деятельности предприятия над уровнем конкурентов. На данном уровне решаются такие задачи, как анализ внешней среды и внутренней обстановки, выбор и разработка стратегии на уровне стратегической зоны хозяйствования, проектирование организационной структуры, выбор степени интеграции и систем управления, определение нормативов поведения и политики в отдельных сферах ее деятельности, обеспечение обратной связи результатов и стратегии. Стратегическое управление обычно охватывает период времени 1…5 лет, минимальный шаг планирования – 1 месяц.

На уровне тактического управления осуществляется среднесрочное планирование хозяйственной деятельности предприятия, формируются портфели заказов на продукцию, разрабатываются планы закупок, планы продаж, планы производства и т. д. Горизонт планирования 1…6 месяцев (в зависимости от длины производственного цикла предприятия). Детализация плана производится по дням.

Уровень оперативного управления – уровень выполнения конкретных действий и учета фактической деятельности, на основе планов, полученных с более высоких уровней управления.

Таблица 1.1. Предлагаемая классификация уровней управления

1.2.2 Бизнес-процессы

Одним из базовых подходов к описанию и формализации системы управления является декомпозиция системы управления по бизнес-процессам [32].

Бизнес-процесс – это совокупность взаимосвязанных мероприятий или работ, направленных на создание определённого продукта или услуги для потребителей. В литературе выделяют три вида бизнес-процессов [33]:

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

2. Операционные – бизнес-процессы, которые составляют основную деятельность компании и создают основной поток доходов. Примерами операционных бизнес-процессов являются Закупки, Производство, Маркетинг, Продажи и Логистика.

3. Поддерживающие (обеспечение) – бизнес-процессы, которые обслуживают основной бизнес. Например, Бухгалтерский учет, Подбор персонала, Техническая поддержка, административно-хозяйственный отдел.

Практически на каждом предприятии схема бизнес-процессов будет отличаться [34], однако, безусловно то, что несмотря на различия, системы бизнес-процессов будут подобны. Рассмотрим один из множества возможных способов декомпозиции системы управления производственного предприятия по бизнес-процессам (рисунок 1.1).

Рисунок 1.1 – Система бизнес-процессов производственного предприятия

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

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

Для каждого типа задач управления необходимо сформулировать общую форму результата решения задачи:

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

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

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

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

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

Рисунок 1.2 – Задачи по уровням управления и бизнес-процессам

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

1.2.3 Описание бизнес-процессов

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

1. производственные процессы;

2. проектирование;

3. организация, планирование и управление;

4. научные исследования;

5. обучение;

6. бизнес-процессы;

7. другие сферы человеческой деятельности.

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

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

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

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

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

1. набор составляющих процесс шагов – бизнес-функций;

2. порядок выполнения бизнес-функций;

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

4. исполнителей каждой бизнес-функции;

5. входящие документы/информацию, исходящие документы/информацию;

6. ресурсы, необходимые для выполнения каждой бизнес-функции;

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

8. параметры, характеризующие выполнение бизнес-функций и процесса в целом.

Для моделирования бизнес-процессов можно использовать различные методы. Метод или методология моделирования включают в себя последовательность действий, которые необходимо выполнить для построения модели, т. е. процедуру моделирования и применяемую нотацию (язык). Наиболее популярной методологией бизнес-моделирования является ARIS, но также известны другие: Catalyst компании CSC, Business Genetics, SCOR (Supply\Chain Operations Reference), POEM (Process Oriented Enterprise Modeling) и др. Язык моделирования имеет свой синтаксис (условные обозначения различных элементов и правила их сочетания) и семантику (правила толкования моделей и их элементов).

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

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

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

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

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

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

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

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

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

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

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

3. структурные, характеризующие морфологию системы – состав подсистем, их взаимосвязи;

4. информационные, отражающие структуры данных – их состав и взаимосвязи.

1.2.4 История развития описания бизнес-процессов

История описания бизнес-процессов насчитывает уже почти столетие, хотя вплоть до начала 1990-х гг., когда термин «бизнес-процесс» вошел в широкое употребление, говорили об описании того, каким образом организация осуществляет свои функции и выполняет те или иные задачи. Развитие методов графического представления и автоматизации бизнес-процессов принято разделять на три этапа, или три «волны». Началом каждой из них явился очередной всплеск интереса к повышению эффективности деятельности предприятий и процессному управлению, происходивший каждый раз на новом качественном уровне. Начало первого этапа относят к 1920-м гг. XX в. и связывают с именем Фредерика Тейлора и его книгой «Принципы научного управления». В этот период впервые была осознана необходимость исследовать бизнес-процессы, описывать их в различных документах и действовать в соответствии с этими описаниями. Описание бизнес-процессов производится в текстовом, табличном и графическом виде, причем последний все более формализуется.

В период «первой волны» для графического представления бизнес-процессов используются блок-схемы, ориентированные графы, сети Петри, методологии SADT, IDEF, DFD. Блок-схемы на основе, определенной в ГОСТ 19.701-90 нотации схем алгоритмов, программ, данных и систем (в англоязычной литературе – ANSI flowcharts), остаются и сегодня простейшим, но практически важным формальным графическим языком описания бизнес-процессов. Пример описания процесса с помощью блок-схемы приведен на рис. 1.3. Блок-схемы позволяют быстро и наглядно показать шаги бизнес-процесса в понятной каждому форме, однако их нотация не предусматривает формализованного описания многих деталей процесса, в частности исполнителей бизнес-функций.

Рисунок 1.3 – Пример простой блок-схемы

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

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

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

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

Начало второго этапа ознаменовал выход книги М. Хаммера и Д. Чампи «Реинжиниринг корпорации: манифест революции в бизнесе», которая возродила в управленческой среде интерес к описанию и анализу бизнес-процессов с целью их радикальной перестройки – реинжиниринга. Реинжиниринг бизнес-процессов предполагает построение двух моделей бизнес-процесса: как есть (англ. as is) и как должно быть (англ. to be), а затем внедрение последней на предприятии.

Как следующий шаг в автоматизации бизнес-процессов в 1990-х гг. появляются системы управления потоками работ WfMS (Workflow Management System) второго поколения, предназначенные для маршрутизации потоков работ любого типа в рамках бизнес-процессов компании. Современные ERP-системы, речь о которых пойдет далее, также содержат внутри себя средства автоматизации бизнес-процессов на основании разработанных моделей, таким образом на завершающей стадии модель бизнес-процесса становится основой автоматизации бизнес-процессов. В качестве примера методологии и средства автоматизации бизнес-процессов второго поколения можно назвать соответственно методологию ARIS и распространенную ERP-систему SAP R/3. Однако существующие на тот момент ERP-системы, имели крайне ограниченные возможности по настройке и изменению процессов, предоставляли только поддерживающие управление потоками работ системы планирования ресурсов предприятия. Поэтому внесение любых существенных изменений в бизнес- процесс превращалось в весьма дорогостоящий и долгосрочный проект по проектированию и разработке программного обеспечения, а модели бизнес-процессов, построенные аналитиками, использовались для более четкой формулировки требований, которые затем передавались программистам.

Негибкость моделей и средств автоматизации, их неспособность обеспечить оперативное реагирование на постоянные изменения в бизнес-среде стали основными недостатками систем «второй волны», стимулировавшими разработку в начале 2000-х гг. методологий следующего – третьего поколения. Манифестом «третьей волны» в моделировании бизнес-процессов можно по праву назвать книгу Г. Смита и П. Фингара «Управление бизнес-процессами: третья волна». На смену радикальному реинжинирингу приходит системное и «плавное» управление. Изменчивость бизнес-процессов, возможность их корректировки в ответ на изменения в бизнесе становятся главным критерием использования информационных технологий как средства, позволяющего получить преимущества на рынке.

Идея методологий и инструментов моделирования третьего поколения состоит в том, чтобы позволить руководству и сотрудникам компании создавать и самим внедрять новые процессы «на лету». Автоматизация процессов производится посредством так называемых систем управления бизнес-процессами BPMS (Business Process Management System), которые дают возможность непосредственно реализовывать бизнес-процессы в соответствии с построенной формальной моделью и не требуют разработки дополнительного программного обеспечения.

Для разработки понятных машине «исполняемых» моделей требуются более точные методы моделирования. К таким методам относятся языки моделирования на базе XML: BPML, BPEL, XPDL. Однако, построение моделей непосредственно на этих языках неудобно для бизнес-пользователей. В этой связи большое внимание разработчики программного обеспечения уделяют средствам конвертирования графических моделей бизнес-процессов в исполняемые. Это позволяет бизнес-аналитику или менеджеру строить модели бизнес-процессов с использованием графической нотации, а затем преобразовывать построенную модель (пока нередко с помощью технического специалиста) в исполняемый вид.

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

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

– OASIS (Organization for the Advancement of Structured Information Standards, осн. в 1993 г.) выпускает спецификации ebXML и BPEL, а также различные стандарты для электронного бизнеса на базе XML и веб-сервисов;

– OMG (Object Management Group, осн. в 1989 г.) выпускает стандарты BPMN и UML, а также MDA и CORBA;

– W3C (World Wide Web Consortium, осн. в 1994 г.) выпускает стандарты WS-CDL, WSCI, а также спецификации XML, технологии веб-сервисов и многие другие;

– WfMC (Workflow Management Coalition, осн. в 1993 г.) выпускает стандарты Wf-XML и XPDL.

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

1.3.1 Основные принципы моделирования бизнес-процессов

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

– Точно определить результат бизнес-процесса и оценить его значение для бизнеса.

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

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

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

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

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

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

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

– Более эффективно внедрить стандарты качества, например, ИСО 9000, и успешно пройти сертификацию.

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

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

– Разобравшись в совокупности бизнес-процессов, понять и описать деятельность предприятия в целом.

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

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

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

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

На рисунке 1.4 показаны основные шаги при построении модели бизнес-процесса.

Рисунок 1.4 – Шаги построения модели бизнес-процесса

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

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

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

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

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

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

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

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

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

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

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

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

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

1. владелец бизнес-процесса и один/два сотрудника того же подразделения компании, помогающих ему;

2. специалист по управлению качеством;

3. бизнес-аналитик(и);

4. представитель ИТ-подразделения;

5. внешний консультант (не обязательно).

1.3.2 Нотация и модель бизнес-процессов (BPMN)

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

BPMN (англ. Business Process Model and Notation, нотация и модель бизнес-процессов) – система условных обозначений (нотация) для моделирования бизнес-процессов. Разработана Business Process Management Initiative (BPMI.org) и поддерживается Object Management Group, после слияния обеих организаций в 2005 году. Последняя версия BPMN – 2.0.

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

По заявлению разработчиков стандарта BPMN, он вобрал в себя лучшие идеи, что имеются в следующих нотациях и методологиях моделирования:

1. UML (Unified Modeling Language, Унифицированный язык моделирования): Activity Diagram (диаграмма деятельности), EDOC (Enterprise Distributed Object Computing, корпоративная распределенная обработка объектов) – Business Processes (бизнес-процессы);

2. IDEF (SADT);

3. ebXML (Electronic Business eXtensible Markup Language, расширяемый язык разметки для электронного бизнеса) BPSS (Business Process Specification Schema, схемы спецификации бизнес-процессов);

4. ADF (Activity-Decision Flow, поток «деятельность-результат») Diagram;

5. RosettaNet;

6. LOVEM (Line of Visibility Engineering Methodology, визуальная методология проектирования);

7. EPC.

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

Элементы (символы) графической нотации BPMN по назначению объединены в категории:

1. объекты потока (Flow Objects);

2. данные (Data);

3. зоны ответственности (Swimlanes);

4. соединяющие элементы (Connecting Objects);

5. артефакты (Artifacts).

В табл. 1.2 приведены символы нотации BPMN и их базовое изображение [39].

Таблица 1.2. Символы нотации BPMN

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

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

События

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

Все события классифицируются по следующим признакам:

1. По времени наступления:

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

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

1.3. Промежуточное событие – все остальные события, возникающие в ходе выполнения процесса. В промежуточное событие обязательно должен входить и выходить один поток. Исключение составляют граничные (Boundary) события, возникающие и обрабатываемые непосредственно либо в самом начале действия, либо в его конце. Такие события отображаются на границе (контуре) действия и у них может быть только либо входящий, либо исходящий поток. Контур события отображается двойной тонкой линией.

2. По возможности прерывания выполнения действия (подпроцесса):

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

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

3. По типу результата действия:

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

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

4. По причине возникновения (триггеру).

Действия

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

Различают три основных вида действий и их разновидности:

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

– сервисная (Service). Задача предназначена для оказания услуги, которая может являться как веб-сервисом, так и автоматизированным приложением;

– отправка сообщения (Send). Задача считается выполненной, если сообщение послано хотя бы один раз;

– получение сообщения (Receive). Задача считается выполненной, если сообщение получено хотя бы один раз;

– пользовательская (User). Характерная задача, выполняемая исполнителем при содействии других людей или программного обеспечения;

– ручное исполнение (Manual). Характерная задача, выполняемая исполнителем без каких-либо средств автоматизации;

– бизнес-правило (Business-Rule). Задача, технология выполнения которой зависит от текущих обстоятельств и выбирается на основе заданного бизнес-правила;

– сценарий (Script). Задача, порядок выполнения операций которой описан на языке, распознаваемом исполнителем. Обычно используется для задач, выполняемых автоматическими средствами;

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

– событийный подпроцесс (Event Sub-Process). Запускается каждый раз, когда происходит одно из стартовых событий. На диаграмме событийный подпроцесс не связан с другими действиями потоками операций. Контур подпроцесса отображается точками;

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

– вызов (Call). Позволяет включать в состав диаграммы повторно используемые задачи и подпроцессы. На диаграмме выделяется жирным контуром.

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

– цикл (Loop). Действие выполняется в цикле с пред- (while) или пост- (repeat-until) условием;

||| или ≡ – многоэкземплярность (Multi-Instance). Параллельное или последовательное выполнение нескольких экземпляров однотипных действий. При последовательном выполнении действие можно рассматривать как цикл с параметром (for);

– компенсация (Compensation). Действие выполняется взамен стандартного при невозможности его удачного завершения;

~ – настраиваемый подпроцесс (Ad-Hoc). Указывается только для подпроцессов. Конкретный состав и последовательность входящих в него действий определяется исполнителем в процессе его выполнения.

В общем случае для действия может быть указано несколько маркеров.

Шлюзы

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

, – эксклюзивный (Exclusive, XOR – исключающее ИЛИ). Предназначен для разделения потока операций на несколько альтернативных маршрутов, т. е. в ходе выполнения процесса может быть активирован только один из предложенных маршрутов. Условия пропуска по исходящему маршруту задается рядом с соответствующей линией в виде логического выражения;

– неэксклюзивный (Inclusive, OR – логическое ИЛИ). Предназначен для разделения потока операций на несколько маршрутов, каждый из которых активируется при условии истинности связанного с ним логического выражения. Таким образом, при выполнении процесса может быть выбрано сразу несколько маршрутов, в т. ч. и ни одного в случае ложности всех выражений;

– комплексный (Complex). Аналогичен неэксклюзивному шлюзу. Отличие заключается в том, что с ним связано одно выражение, которое определяет, какие из потоков операций будут активированы;

– параллельный (Parallel, AND – логическое И). Предназначен для слияния/ветвления одновременно (параллельно) выполняемых потоков операций;

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

– эксклюзивный, основанный на событиях, запускающий процесс (Exclusive Event-Based Gateway to start a Process). Аналогичен предыдущему, но используется в качестве начального символа процесса (подпроцесса). Не имеет входящих потоков;

– параллельный, основанный на событиях, запускающий процесс (Parallel Event-Based Gateway to start a Process). Аналогичен предыдущему, но возможна активация сразу нескольких маршрутов в случае срабатывания событий, с которыми они связаны. Возможно асинхронное выполнение маршрутов (связанных потоков операций и действий). Т. е. после активации и начала выполнения одного из маршрутов, другие маршруты тоже могут быть активированы и выполнены, пока не наступил момент завершения процесса (подпроцесса). Не имеет входящих потоков.

Объект данных

С помощью дополнительных маркеров на диаграмме может быть показана специфика использования и содержания данных:

– входные данные (Data Inputs). Исходные ТМЦ или информация для выполнения действий. Отображается у верхнего края символа;

– выходные данные (Data Outputs). Результат действия. Отображается у верхнего края символа;

||| – набор данных (Data Collection). Коллекция или массив однотипных данных. Отображается у нижнего края символа.

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

Потоки операций

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

– условный поток операций (Conditional Sequence Flow). Используется при ветвлении потоков. Обычно отображается исходящим из действия, чтобы не отображать на диаграмме шлюз. Условия активации потока задается рядом в виде логического выражения;

– поток операций по умолчанию (Default Sequence Flow). Используется при ветвлении потоков. Может исходить из действия или шлюза. Не связан ни с каким логическим выражением. Поток по умолчанию активируется, если активация других потоков в соответствии с их логическими выражениями или событиями невозможна.

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

Рисунок 1.5 – Пример BPMN диаграммы «Схема сквозного планирования»

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

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

Система управления – систематизированный набор средств сбора сведений о подконтрольном объекте и средств воздействия на его поведение, предназначенный для достижения определённых целей. Объектом системы управления могут быть как технические объекты, так и люди [41]. В случае, если в качестве объекта управления выступает производственное предприятие как организационная структура, будем говорить о системе управления производственным предприятием.

АВТОМАТИЗИРОВАННАЯ СИСТЕМА УПРАВЛЕНИЯ (АСУ) (automated, automatized control system (ACS), computerized control system, management information system (MIS)) – система управления, в которой применяются современные электронные средства обработки данных и экономико-математические методы для решения основных задач управления производственно-хозяйственной деятельностью. Это человеко-машинная система, в ней ряд операций и действий передается для исполнения машинам и другим устройствам (особенно это относится к т. н. рутинным, повторяющимся, стандартным операциям и расчетам), но главное решение всегда остается за человеком. Этим АСУ отличаются от автоматических систем, т. е. таких технических устройств, которые действуют самостоятельно по установленной для них программе, без вмешательства человека [42].

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

Интеллектуальная система (ИС, англ. intelligent system) – это техническая или программная система, способная решать задачи, традиционно считающиеся творческими, принадлежащие конкретной предметной области, знания о которой хранятся в памяти такой системы [43]. В технологиях принятия решений интеллектуальная система – это информационно-вычислительная система с интеллектуальной поддержкой, решающая задачи без участия человека – лица, принимающего решение (ЛПР) [43]. Понятие интеллектуальной системы тесно связано с областью информатики, называемой искусственным интеллектом (ИИ). Существует много различных определений ИИ. Ниже приведены некоторые из них [43]:

«Автоматизация видов деятельности, которые мы ассоциируем с человеческим мышлением (human thinking), таких как принятие решений, решение проблем, обучение…» (Belman, 1978);

«Изучение того, как заставить компьютеры делать вещи, которые в настоящее время лучше делают люди» (Rich, Knight, 1991) [43].

К одним из бурно развивающихся технологий ИИ относятся:

1. Мягкие вычисления (нечеткие множества, нечеткая логика и т. п.).

2. Интеллектуальные агенты и мультиагентные системы.

3. Интеллектуальный анализ данных [43].

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

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

2. система является интеллектуальной системой с широким использованием технологий искусственного интеллекта;

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

4. способна решать задачи управления в различных режимах:

a. автоматическом режиме (без привлечения человека),

b. автоматизированном режиме (с привлечением лиц, принимающих решения),

c. режиме обучения и моделирования (для обучения персонала и моделирования деятельности).

1.4.1 Автоматизированные системы управления производством

С развитием компьютерной техники и с увеличением сложности производственных процессов развитие получили автоматизированные системы управления, специализирующиеся на различных уровнях управления предприятия [44]. Ниже приведены основные виды автоматизированных систем управления производством актуальные на сегодняшний день:

1. ERP-системы (англ. Enterprise Resource Planning, планирование ресурсов предприятия) [45] – автоматизированные системы управления, реализующие в себе процессы управления производством, управления трудовыми ресурсами, финансового менеджмента и управления активами, ориентированные на непрерывную балансировку и оптимизацию ресурсов предприятия, обеспечивающие общую модель данных и процессов для всех сфер деятельности предприятия. Понятие ERP предложено в качестве развития стандарта MRP II. Системы данного класса охватывают стратегический и тактический уровни управления, объединяя все процессы предприятия в единую систему.

2. APS-системы (сокр. от англ. Advanced Planning & Scheduling – усовершенствованное планирование) [46] – программное обеспечение для синхронного производственного планирования, главной особенностью которого является возможность построения сквозного расписания работы оборудования в рамках всего предприятия. Полученные таким образом частные расписания производственных подразделений являются взаимосвязанными с точки зрения изделия и его операций (требование SCM – Supply Chain Management, управление цепочками поставок). Эта важная особенность позволяет системе выполнять перепланирование цепей поставок в режиме реального времени, реагируя на любые отклонения в выполнении планов. Данный класс программного обеспечения находится на стыке ERP и MES систем, обладая признаками той и другой. Многие существующие ERP-системы имеют встроенные APS модули.

3. MES (manufacturing execution system, система управления производственными процессами) [47] – специализированное прикладное программное обеспечение, предназначенное для решения задач синхронизации, координации, анализа и оптимизации выпуска продукции в рамках какого-либо производства. MES-системы относятся к классу систем управления уровня цеха, но могут использоваться и для интегрированного управления производством на предприятии в целом. Данный класс информационных систем работает от тактического уровня до оперативного уровня управления.

4. SCADA (Supervisory Control And Data Acquisition – диспетчерское управление и сбор данных) – программный пакет, предназначенный для разработки или обеспечения работы в реальном времени систем сбора, обработки, отображения и архивирования информации об объекте мониторинга или управления. Данные системы относятся к оперативному уровню управления.

5. Автоматизированная система управления технологическим процессом (АСУ ТП) – группа решений технических и программных средств, предназначенных для автоматизации управления технологическим оборудованием на промышленных предприятиях.

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

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

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

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

Рисунок 1.6 – Развитие систем планирования и контроля производства

1.4.3 Технология ROP

По мере развития компьютерной техники шире становились возможности в области управления производством на промышленных предприятиях. Эволюция информационных систем производственного управления на базе технологий ROP, MRP и MRPII [48] обеспечивалась техническим прогрессом в информационных технологиях. Эволюция систем происходила в условиях изменяющейся экономической обстановки (в первую очередь в США). Ограничения, заложенные в концепцию систем, компенсировались тем, что экономическая ситуация была достаточно стабильна для того, чтобы системы могли работать, принося положительный эффект предприятиям, использовавшим системы.

В 60-е годы основным конкурентным преимуществом была стоимость (себестоимость), в результате которой была разработана целенаправленная производственная стратегия, основанная на крупносерийном производстве, минимизации издержек в стабильных экономических условиях. Новая для того времени компьютеризированная система планирования по точке перезаказа (Reorder Point – ROP) удовлетворяла базовые потребности по планированию производства этих фирм. Суть ROP сводится к измерению параметров, характеризующих состояние склада: текущий уровень запаса продукции и значение точки перезаказа для неё. Если значение точки перезаказа превышает текущий уровень запаса, запускается процедура пополнения продукции за счёт внутреннего производства или закупки у внешнего поставщика (рисунок 1.7).

Рисунок 1.7 – Принципиальная схема планирования по точке заказа

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

1. значение текущего запаса продукции на складе;

2. значение точки перезаказа для продукции;

3. время пополнения запаса (плановые сроки поставки);

4. объём заказа.

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

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

ТочкаПерезаказа = ПотреблениеВДень / ПлановыеСрокиПоставки, где ПотреблениеВДень характеризует объём потребляемой продукции за 1 день, ПлановыеСрокиПоставки – сроки поставки материалов от поставщика на склад в днях.

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

1.4.4 Технология MRP

На следующем этапе развития предприятия начали автоматизировать процессы формирования, учета и отслеживания календарной потребности в готовой продукции (заказы клиентов, прогнозы продаж и т. д.). Следующим шагом стал анализ плана выпуска готовых изделий с целью определения календарной потребности в комплектующих изделиях, сырье и материалах, деталях и сборочных единицах с учетом наличного складского запаса. Эта задача была решена в компьютерном варианте в начале 60-х гг. и получила название MRP (Material Requirements Planning) – планирование потребности в материалах. Термин был введен в употребление Орлицки (Orlicky), который осознал потенциал применения вычислительной техники для решения задачи управления производственными запасами. Ранние компьютерные приложения MRP были построены на основе процессора спецификаций (Bill of Material Processor – BOMP), преобразовавшего дискретный план производства родительских номенклатурных позиций в дискретный план производства и закупки номенклатурных позиций-компонентов.

Основой системы стали данные о составе изделий и нормах расхода сырья, материалов и компонентов на единицу измерения готовой продукции. В теории MRP эта информация получила название BOM (Bill of Material) (спецификация) [49]. BOM может быть одно- или многоуровневым, обычным или плановым. Одно- или многоуровневый ВОМ означает, что для описания структуры продукта используется обычный список или многоуровневое древовидное описание. Чем глубже эта древовидная структура, тем более жесткие требования предъявляются к точности данных о номенклатурных позициях, включаемых в эту структуру (рисунок 1.8).

Рисунок 1.8 – Пример представления древовидной спецификации в 1С ERP

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

С начала 70-х гг. популярность MRP поддерживается APICS (American Production and Inventory Control Society) [45], начавшей свою деятельность в области продвижения MRP с попытки убедить людей в том, что MRP является решением многих проблем, ибо дает возможность сформировать интегрированные системы налаживания коммуникаций внутри компании и поддержки принятия решений. Тем самым MRP помогает руководящим работникам находить наиболее эффективные способы управления бизнесом в целом. APICS подчеркивала, что для успешного внедрения программ MRP необходимы понимание со стороны менеджмента и тотальное обучение персонала. Роль же математических методик оптимизации принимаемых решений была APICS уменьшена. Подчеркивалось, что реальными проблемами являются проблемы дисциплины, образования, понимания и коммуникаций.

Явным недостатком на данном этапе развития технологии MRP была невозможность обновить результатную информацию, получаемую в ходе работы MRP, т. е. подстроиться под изменения, возникающие в случае изменений открытых заказов. Из-за этого первые MRP-системы называли «запустил и забыл» (launch and forget). В свою очередь, возможность обновления очень важна, так как среда, в которой используется MRP, весьма динамична, а частые изменения размеров заказов и сроков их выполнения не являются редкостью. Отсюда вытекает необходимость отслеживать текущее состояние открытых заказов.

Данная фаза развития стандарта MRP имела место при преобладающем характере пакетной обработки информации на удаленных вычислительных центрах (кустовых или корпоративных). Тогда интерактивные технологии развития еще не получили. Если учесть, что в настоящее время при современном уровне развития вычислительной техники, один запуск процедуры MRP в режиме полного пересчета, согласно статистическим данным, занимает от 3 до 8 часов (в среднем), можно представить, насколько возможности для оперативного моделирования ситуации были ограничены тогда, и становится ясно, что анализ «а что будет, если?..» практически не проводился. По сути, MRP просто фиксировала статический план в «развернутом» виде.

1.4.5 Технология MRPI/CRP

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

Для работы механизма CRP необходимы три массива исходных данных:

1. Данные о главном календарном плане производства (MPS). Они являются исходными и для MRP.

2. Данные о рабочих центрах. Рабочий центр, как отмечает APICS [45], – это определенная производственная мощность, состоящая из одной или нескольких машин (людей и/или оборудования), которая в целях планирования потребности в мощностях (CRP) и подробного календарного планирования может рассматриваться как одна производственная единица. Можно сказать, что рабочий центр – это группа взаимозаменяемого оборудования, расположенная на локальном производственном участке. Для работы CRP необходимо предварительное формирование рабочего календаря рабочих центров с целью вычисления доступной производственной мощности.

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

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

После завершения работы CRP становятся доступны результаты расчета мощностей (рисунок 1.9)

Рисунок 1.9 – Результат расчета CRP за период

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

CRP и MRP можно с некоторой долей условности отнести к системам поддержки принятия решений, так как они позволяют просчитывать последствия, хотя и не выдают никаких практических вариантов преодоления возникших проблем. Иногда технологию MRP называют еще MRP I. Можно отметить, что налаженная технология MRP I/CRP при наличии достаточных вычислительных мощностей позволяет, по сути, осуществлять моделирование ситуации.

1.4.6 Замкнутый цикл MRP (Closed loop MRP)

Следующим этапом развития стал «Замкнутый цикл MRP» (closed loop MRP), предложенный в конце 70-х гг. Оливером Уайтом, Джорджем Плосслом и другими (Oliver Wight, George Plossl and others). Основная идея данного усовершенствования технологии MRP заключается в создании замкнутого цикла путем налаживания обратных связей, улучшающих отслеживание текущего состояния, поддержание мониторинга выполнения плана снабжения и производства. В результате применения нового метода значительно повышен уровень достоверности и точности плановых показателей. Дополнительно к системе MRP новый метод позволил автоматизировать фазы детального планирования и учета выполнения планов:

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

2. учет входного/выходного материального потока;

3. диспетчирование хода производства и поставок;

4. составление отчетности о предполагаемом отставании от графиков выпуска, графиков поставок и т. д.

Дополнительные функции обеспечивают обратную связь и гибкость планирования с учетом внешних экономических факторов (уровень спроса, состояние открытых заказов, движение материального потока и т. п.). В процесс управления вовлечены бизнес-процессы, которые связаны со снабжением и производством, но не бизнес-процессы продаж и финансового учета. Было необходимо реализовать мониторинг (диспетчирование) выполнения плана снабжения и производственных операций, что позволяло снять те ограничения степени достоверности результата планирования, ранее присущие MRP I, которые существовали из-за невозможности отследить состояние открытых заказов. С добавлением указанных функций к MRP I/CRP был сформирован стандарт «Замкнутый цикл MRP», охватывающий все стороны бизнеса, связанные с изготовлением продукции.

Функции учета фактической деятельности были введены к MRP как дополнительная сущность к плану, и весь учет изначально строился «от плана». С сожалением следует отметить, что практика реализации проектов внедрения автоматизированных систем управления в России часто строится только на учете фактического выполнения операций, вообще без использования алгоритмов MRP, что делает АСУ, полученные в результате, малопригодными для реального управления предприятием. Также распространенным случаем являются системы, где функции планирования и учета выполняются полностью независимо друг от друга (например, планирование в Excel, а учет в «1С Управление производственным предприятием»), что делает невозможным сопоставление данных план-факт. Вклад таких систем в процессы управления производством можно считать равным нулю или же отрицательным. Наверное, именно этот факт стал причиной того, что подавляющее количество специалистов и руководителей на производстве (специалистов служб планирования, диспетчеров, начальников цехов и т. д.) крайне скептически относятся к возможности автоматизации процессов управления производством.

Для точности отражения информации следует привести определение, которое APICS дает методологии «Замкнутый цикл MRP» [45]: «Система, построенная вокруг планирования потребности в материалах (MRP), которая включает дополнительные плановые функции, а именно планирование производства (укрупненное планирование) (production planning (aggregate planning)), разработку главного календарного плана производства (master production scheduling) и планирование потребности в мощностях (capacity requirements planning). После того как вышеописанные фазы планирования пройдены и планы были приняты как реалистичные и достижимые, начинается исполнение планов. Это включает в себя такие функции управления производством, как измерение входного/выходного материального потока (мощности) (input-output (capacity) measurement), формирование подробных графиков и диспетчирование, а также отчетность по предполагаемому отставанию от графиков от завода и от поставщиков, формирование графиков поставщиков и т. д. Термин «замкнутый цикл» означает, что существует обратная связь от функций исполнения, с тем чтобы планирование было всегда корректным» [50]. Следует отметить, что в процесс вовлечены только операции, связанные со снабжением и производством, а процессы сбыта (продаж) и финансового учета технологией не задействованы, хотя их включение в MRP-стандарт позволило бы нам не только замкнуть цикл управления, но и наладить полнофункциональную цепь поставок товарно-материальных ценностей по схеме «снабжение – производство – сбыт» и довести продукт до потребителя, гармонизировав тем самым комплексную технологию управления бизнесом.

MRP II (англ. manufacturing resource planning – планирование производственных ресурсов) [45] – стратегия производственного планирования, обеспечивающая как операционное, так и финансовое планирование производства, обеспечивающая более широкий охват ресурсов предприятия, нежели MRP. В отличие от MRP, в системе MRP II производится планирование не только в материальном, но и в денежном выражении. Реализуется внедрением прикладных программных пакетов. MRP II задаёт принципы детального планирования производства предприятия, включающая учёт заказов, планирование загрузки производственных мощностей, планирование потребности во всех ресурсах производства (материалы, сырьё, комплектующие, оборудование, персонал), планирование производственных затрат, моделирование хода производства, его учёт, планирование выпуска готовых изделий, оперативное корректирование плана и производственных заданий. Стандарт MRP II (Manufacturing Resource Planning) позволил развить технологию планирования, ориентированную на применение корпоративных информационных систем, очертив полный контур задач управления промышленным предприятием на оперативном уровне.

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

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

2. MRP I/CRP предоставляет информацию о количестве основного производственного персонала, уровне часовых тарифных ставок и нормах времени на выполнение технологических операций (в описании технологических маршрутов), о возможных сверхурочных работах и т. д., необходимую для принятия предприятием обязательств по выплате заработной платы.

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

Необходимо отметить, что для обеспечения достоверности результатов критически необходимо обеспечение точности и своевременности входной информации нормативного и оперативного характера (чтобы избежать реализации принципа GIGO – garbage in, garbage out).

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

Приведем краткую характеристику модулей MRP II:

1. Управление продажами:

1.1. управление спросом (Demand Management);

1.2. управление продажами (Sales & Operations Planning);

1.3. учет продаж и взаиморасчетов с клиентами;

1.4. планирование ресурсов распределения (Distribution Resource Planning).

2. Планирование ресурсов:

2.1. главный календарный план производства (Master Production Schedule);

2.2. подсистема спецификаций (Bill of Material Subsystem);

2.3. планирование потребности в материалах (Material Requirements Planning);

2.4. планирование потребности в мощностях (Capacity Requirements Planning).

3. Управление закупками:

3.1. подсистема операций с запасами (Inventory TransactionSubsystem);

3.2. управление закупками (Purchasing);

3.3. учет закупок и взаиморасчетов с поставщиками;

3.4. подсистема запланированных поступлений по открытым заказам (Scheduled Receipts Subsystem).

4. Управление производством:

4.1. оперативное управление производством (Shop Floor Control или Production Activity Control);

4.2. управление входным/выходным материальным потоком (Input/Output Control);

4.3. инструментальное обеспечение (Tooling или Tool Planning and Control).

5. Финансы моделирование и контроллинг:

5.1. финансовое планирование (Financial Planning Interfaces);

5.2. моделирование (Simulation);

5.3. учет затрат;

5.4. оценка деятельности (Performance Measurement).

Рисунок 1.10 – Модули MRP II

1.5.1 Управление продажами

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

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

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

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

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

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

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

Управление продажами (Sales & Operations Planning)

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

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

Учет продаж и взаиморасчетов с клиентами

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

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

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

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

1.5.2 Планирование ресурсов

Главный календарный план производства (Master Production Schedule)

Главный календарный план производства описывает план из номенклатурных позиций независимого спроса (что производить, когда производить, сколько производить). Все остальные календарные планы в MRP базируются на главном календарном плане производства и формируются путем «разворачивания» – от потребности в готовой продукции к потребности в компонентах и материалах через описанные структуры продуктов.

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

Подсистема спецификаций (Bill of Material Subsystem)

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

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

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

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

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

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

5. Информация об используемом для выполнения операций оборудовании с указанием нормативов времени для выполнения каждой операции. Как правило, вместо конкретных единиц оборудования указываются «рабочие центры» [45], описанные в MRP I/CRP.

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

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

Для того, чтобы снизить риски влияния качества данных в спецификациях на работу MRP II используют следующие практические подходы:

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

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

3. Внедрение регламентов актуализации информации, подразумевающих разделение спецификаций по степени критичности для производства и установлению различных требований к периодичности актуализации и требований к качеству данных в зависимости от степени критичности. Данный подход позволит получить качественную информацию для планирования производства на критических участках производства и удовлетворительное качество информации на периферии. Более подробно про «критические цепи» будет рассказано в главе 2.2.

Планирование потребности в материалах (Material Requirements Planning)

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

Планирование потребности в мощностях (Capacity Requirements Planning)

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

Принцип работы данного модуля был уже описан ранее в главе, посвященной MRP I/CRP, но с важным уточнением, что потребность в мощностях калькулируется на основании как плановых, так и запущенных в производство (открытых) заказов. Плановые заказы поступают из модулей главного календарного планирования (MPS) и планирования потребности в материалах (MRP), а открытые извлекаются из подсистемы планирования и диспетчирования на уровне цеха (shop scheduling and dispatching system).

Подсистема операций с запасами (Inventory TransactionSubsystem)

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

1.5.3 Управление закупками

Управление закупками (Purchasing)

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

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

Учет закупок и взаиморасчетов с поставщиками

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

Подсистема запланированных поступлений по открытым заказам (Scheduled Receipts Subsystem)

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

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

1.5.4 Управление производством

Оперативное управление производством (Shop Floor Control или Production Activity Control)

Оперативное управление производством, или, иначе говоря, «Планирование и диспетчирование работы цеха» (Shop Scheduling and Dispatching). Данный модуль предназначен для управления приоритетами между работниками планирования и цеховым персоналом. Он позволяет видеть календарный план работы цеха в разрезе производственных заказов, рабочих центров и производственных операций, а также отслеживать его фактическое выполнение. Для сравнения отметим, что MRP и CRP предоставляют информацию, исходя только из производственных заказов и дат их выполнения.

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

Управление входным/выходным материальным потоком (Input/Output Control)

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

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

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

Инструментальное обеспечение (Tooling или Tool Planning and Control)

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

1.5.4 Финансы моделирование и контроллинг

Финансовое планирование (Financial Planning Interfaces)

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

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

2. расходование денежных средств (закупка материалов, затраты труда, переменные накладные расходы);

3. получение денежных средств;

4. распределение постоянных накладных расходов (косвенного характера).

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

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

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

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

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

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

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

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

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

Основными объектами моделирования в MRPII являются: