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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Реферат на тему:

«Интегрированные автоматизированные системы управления производством (ИАСУ)»

Выполнил:

студент _3_курса

ЗАТ 1-19____ группы

Казаков К.

Казань 2022



Содержание

Введение

1. Философия и стандарты планирования

1.1 Принципы автоматизации

1.2 Что дает автоматизация

1.3 Управление, синхронизированное с потребителем

1.4 «Блеск и нищета» комплексной автоматизации

2. Моделирование бизнес-процессов

2.1 Реинжиниринг корпорации

2.2 Проектирование корпоративных ПС

2.3 Методы и средства проектирования

2.4 Методологическое обеспечение

2.5 IDEFO

2.6 Инструментальные средства моделирования

3. АСУП: Проблемы выбора и внедрения

3.1 Малый и большой реинжиниринг

3.2 Искусство внедрения АСУП

3.3 Два подхода к автоматизации

3.4 ERP или не-ERP

3.5 Безболезненное внедрение

3.6 Реальность для систем MRPII

Заключение

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



Введение

Цель работы - рассмотреть философию и стандарты планирования, моделирование бизнес-процессов, проблемы выбора и внедрения автоматизированных систем управления предприятием.

Актуальность данного вопроса велика, т.к. на современном этапе большинство производств начинают внедрение АСУП.

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

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

Для производственного предприятия АСУП призваны решать пять основных задач:

- планирование;

- подготовка;

- обеспечение производства;

- производство продукции;

- сбыт продукции.

1. Философия и стандарты планирования

1.1 Принципы автоматизации

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

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

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

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

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



1.2 Что дает автоматизация

Управленческий учет и финансовый контролинг для руководителей и сокращение рутинных операций для менеджеров - вот то, что сразу ощутимо после внедрения АСУП.

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

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

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



1.3 Управление, синхронизированное с потребителем

Если концепция ERP вписывалась в рамки эпохи качества, то с приходом эпохи потребителя возникла еще одна методология управления производственными ресурсами - CSRP (Customer Synchronized Resource Planning - планирование ресурсов, синхронизированное с потребителем). Реализация CSRP позволяет управлять заказами клиентов и, в целом, всей работой с ними «тоньше», чем это было возможно до настоящего времени. Детальный анализ стоимости заказа и даже конкретных товаров в его составе стал возможен уже на этапе его оформления с учетом конкретных технологических решений. При расчете себестоимости товара можно даже учесть все дополнительные операции по тестированию и обслуживанию заказа, не говоря уже о послепродажном обслуживании.

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

Таким образом, если MRP, MRP-II, ERP ориентировались на внутреннюю организацию предприятия, то методология CSRP обеспечивает полный жизненный цикл продукции - от ее проектирования с учетом требований заказчика до гарантийного и сервисного обслуживания после продажи. Основная суть концепции CSRP в том, чтобы интегрировать заказчика или покупателя в АСУП.

С CSRP тесно связана быстро набирающая обороты технология CRM (Customer Relationship Management - управление отношениями с потребителями). Благодаря ей, компании переходят от простых учетных карточек к более сложным системам, учитывающим особенности и предпочтения потребителей.

1.4 «Блеск и нищета» комплексной автоматизации

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

- Информированность.

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

- Управляемость.

Формализация бизнес-процессов компании предохраняет ее от ошибок;

- Интегрированность.

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

- Контроль.

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

- Критичность одной ошибки.

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

- Увеличение нагрузки на персонал.

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

- Наличие специально подготовленного персонала.

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

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



2. Моделирование бизнес-процессов

2.1 Реинжиниринг корпорации

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

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

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

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

В эпоху постиндустриального бизнеса корпорации организуются и развиваются на основе идеи интеграции отдельных операций в единые бизнес-процессы, т.е. наборы операций, которые, взятые вместе, создают результат, имеющий ценность для потребителя. Это - основной тезис книги Майкла Хаммера и Джеймса Чампи «Реинжиниринг корпорации: манифест революции в бизнесе», ставшей настольной книгой современного бизнеса.

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

Снова три «К».

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

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

Элементы «алмазной» модели.

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

- бизнес-процессы компании;

- трудовые задания и организационные структуры;

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

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

Объектом реинжиниринга являются процессы, а не организации, т. е. под реинжиниринг попадают не отделы предприятия, а работа, выполняемая персоналом этих отделов (business process reengineering-BPR).

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

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

2.2 Проектирование корпоративных ПС

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

- информация об объекте проектирования;

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

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

- знания о методах и средствах моделирования и анализа систем;

- программные средства (инструменты) для моделирования и анализа;

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

- строится модель «as-is» (как есть), как снимок существующих бизнес-процессов;

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

- строится модель бизнеса «to-bе» (как будет) и утверждается план работ по переходу от модели «as-is» к модели «to-be».

Требования к описанию бизнес-процессов.

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

- простым и понятным экспертам предметной области;

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

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

Системный анализ.

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

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

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

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

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

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

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

- сформировать состав программных продуктов, которые необходимо приобрести в рамках создания ИС;

- составить предварительный укрупненный план проектирования и реализации базовой версии ИС;

- оценить трудозатраты разработки новой ИС;

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

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

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

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

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

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

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

2.3 Методы и средства проектирования

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

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

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

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

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

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

2.4 Методологическое обеспечение

Общие сведения

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

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

Такая система взаимодействия имеет следующие основные аспекты:

- административный;

- финансовый;

- материальный (товарный);

- информационный;

- коммуникационный.

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



Методологии IDEF.

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

IDEF-методологии создавались в рамках предложенной ВВС США программы компьютеризации промышленности, в ходе реализации которой выявилась потребность в разработке методов анализа процессов взаимодействия в производственных (промышленных) системах.

Особенностью рассматриваемого семейства методологий является:

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

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

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

Перечислим наиболее распространенные стандарты семейства IDEF:

- IDEF0.

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

- IDEF1.

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

- IDEF1X (IDEF1 Extended).

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

- IDEF2.

Методология динамического моделирования развития систем. Компьютерные алгоритмы позволяют превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе «раскрашенных сетей Петри» (Color Petri Nets);

- IDEF3.

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

- IDEF4.

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

- IDEF5.

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

2.5 IDEFO

Основные понятия.

Так как на практике наиболее часто используется методология IDEF0, то более подробно остановимся на ее представлении. Эту методологию принято считать последовательницей графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique). IDEFO как стандарт был разработан в 1981 году в рамках программы автоматизации промышленных предприятий ICAM (Integrated Computer Aided Manufacturing) и, как уже упоминалось выше, предлагался для ВВС. С 1981 года IDEFO претерпела несколько незначительных изменений, и последняя его редакция была выпущена в конце 1993 года.

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

- функциональный блок.

Графически изображается в виде прямоугольника и определяет конкретную функцию для рассматриваемой системы. При этом каждый функциональный блок должен иметь свой уникальный идентификационный номер. Каждая из четырех сторон функционального блока имеет своё определенное значение. Верхняя сторона имеет значение «Управление» (Control), левая сторона - «Вход» (Input), правая сторона - «Выход» (Output) и нижняя сторона - «Механизм» (Mechanism);

- интерфейсная дуга (потоки, стрелки).

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

- лекомпозиция.

Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. Декомпозиция позволяет постепенно и структурировано представлять модель системы в виде иерархической структуры отдельных диаграмм. В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint). Цель определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь, а точка зрения - основное направление развития модели и уровень необходимой детализации. Для того, чтобы не перегружать диаграммы и не делать их сложными для восприятия, в IDEF0 предусмотрено туннелирование, которое обозначается в виде двух круглых скобок вокруг начала интерфейсной дуги. Это указывает на то, что обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из «туннеля») только на этой диаграмме;

- глоссарий.

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

Ограничения диаграмм.

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

- количество функциональных блоков на диаграмме - от 3 до 6:

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

Коллективная работа.

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

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

- создание черновика (Model Draft) модели на основе имеющихся положений, документов и результатов опросов;

- распространение черновика для рассмотрения, согласований и комментариев (до тех пор, пока авторы и читатели не придут к единому мнению);

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

2.6 Инструментальные средства моделирования

Для системного и структурно-функционального анализа применяют так называемые инструментальные CASE-средства (Computer Aided Software/System Engineering), которые позволяют моделировать бизнес-процессы, базы данных, компоненты программного обеспечения, деятельность и структуру организаций на компьютере.

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

- локальные, поддерживающие один тип моделей и методов (Design/IDEF, ProCap, S-Designor, «CASE. Аналитик»);

- малые интегрированные, поддерживающие несколько типов (до 5) моделей и методов (ERwin, BPwin);

- средние интегрированные, поддерживающие 5-15 типов моделей и методов (Rational Rose, Paradigm Plus, Designer/2000);

- крупные интегрированные, поддерживающие более 15 типов моделей и методов (ARIS Toolset).

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

Характерными особенностями малых интегрированных средств моделирования является наличие в инструментальном средстве независимых компонентов и интеграция. Типичная сфера использования малых интегрированных средств - решение задач так называемой «лоскутной» автоматизации предприятия. Типичный представитель малых интегрированных средств моделирования - комплект программных продуктов Platinum Technology, основанный на пакетах BPwin (рис. 2.1) (новое название AIIFusion Process Modeler) (www.bpwin.ru)и ERwin (новое название AIIFusion ERwin Data Modeler) (www.erwin.ru).



Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рис. 2.1 - Моделирование бизнес-процессов в среде BPwin

BPwin поддерживает 3 методологии моделирования (IDEFO, IDEF3 и DFD) и обеспечивает интеграцию моделей трех типов без экспорта или импорта данных. Интеграция выполняется как слиянием нескольких моделей, так и переключением на различные методологии в процессе разработки отдельных диаграмм модели. Предусмотрено расширение возможностей анализа систем как в самом пакете BPwin (функционально-стоимостный анализ), так и с помощью экспорта данных в другие пакеты. В ERwin поддерживается несколько разновидностей методологии информационного моделирования, основанной на ER-диаграммах («сущность-связь»).

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

- диаграммы прецедентов (Use Cases Diagrams);

- диаграммы классов (Class Diagrams);

- диаграммы последовательности (Sequence Diagrams);

- диаграммы сотрудничества (Collaboration Diagrams);

- диаграммы состояний (State Diagrams);

- диаграммы действий (Activity Diagrams);

- компонентные диаграммы (Component Diagrams);

- диаграммы развертывания (Deployment Diagram).

Пакет Paradigm Plus ориентирован на методологию OOCL (Object Oriented Change and Learning) и компонентную технологию проектирования и разработки, обеспечивая поддержку диаграмм различных методов (UML, CLIPP, TeamFusion, ОМТ, Booch, OOCL, Martin/Odell, Shlaer/ Mellor, Coad/Yourdon). В состав Designer/2000 входят Process Modeller (разработки моделей процессов) и System Modeller (модели иерархии функций (Function Hierarchy Diagrammer), модели потоков данных (Dataflow Diagrammer) и модели типа «сущность-отношение» (Entity Relationship Diagrammer)).

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

Кроме того, RUP управляется сценариями пользователей (или прецедентами). Сценарий пользователя (Use Case) - это описание последовательности действий пользователя при выполнении определенной операции. Сценарии пользователей позволяют более точно представить разработчикам, что же должна делать система и как именно она должна это делать.

Процесс проектирования в RUP имеет четыре фазы: исследование (Inception), уточнение плана (Elaboration), построение (Construction) и развертывание (Transition). На каждой из фаз основное внимание уделяется разным процессам.

Методология RUP основана на 9 основных потоках:

1) бизнес-анализ;

2) сбор требований и управление требованиями;

3) анализ и моделирование;

4) кодирование;

5) тестирование;

6) управление конфигурацией и изменениями;

7) управление проектом;

8) создание и поддержка среды разработки;

9) развертывание.

Любой проект в RUP проходит четыре фазы, а через эти фазы проходят и все девять потоков. Каждая фаза, в свою очередь, разбивается на итерации.

Неотъемлемую часть RUP составляют артефакты и роли. Артефактом (Artefact) называется продукт, который создается и используется в процессе разработки ПО. За создание артефакта отвечает определенная роль. В RUP 2000, например, насчитывается более 30 ролей и более 50 артефактов.

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

Итеративная разработка позволяет на ранней стадии получить работающую версию продукта и выявить критичные недостатки. Благодаря управлению требованиями, программный продукт более точно соответствует ожиданиям заказчика. Визуальное моделирование позволяет эффективно бороться с возрастающей сложностью систем. Модели помогают понять, как на самом деле работает система, что она делает и как она это делает. Инструментальная поддержка проверки качества обеспечивается целым рядом программ: Rational Purify, Rational PureCoverage, Rational Quantify, Rational Robot. Отслеживание изменений позволяет оперативно реагировать на изменение требований заказчика либо на изменяющиеся условия внешней среды. Инструментальная поддержка обеспечивается Rational ClearCase и Rational ClearQuest.

К крупным интегрированным средствам моделирования относят систему, предназначенную для проектирования крупных АСУП класса ERP. Это семейство ARIS (ARIS Toolset, ARIS Easy Design) от компании IDS Sheer AG. Принадлежность к категории ERP для средства моделирования означает, что оно предназначено для выполнения комплексного анализа на всех стадиях разработки АСУП класса ERP.

ARIS обеспечивает четыре различных «взгляда» на моделирование и анализ:

- Процессы;

- Функции;

- Данные;

- Организация.

Для каждого «взгляда» поддерживаются три уровня анализа (требования, спецификации, внедрение). Каждый из уровней анализа состоит из своего комплекта моделей различных типов, в том числе диаграмм UML, диаграмм SAP/R3 и др. Каждый объект моделей ARIS имеет множество атрибутов, которые позволяют контролировать процесс разработки моделей, определять условия для выполнения функционально-стоимостного анализа, имитационного моделирования, взаимодействия с системами документооборота и т.д.

3. АСУП: Проблемы выбора и внедрения

3.1 Малый и большой реинжиниринг

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

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

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

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

- снизить транспортно-заготовительные расходы на 60 %;

- сократить производственный цикл по заказным и базовым изделиям соответственно на 50 % и 30 %;

- снизить задержки с отгрузкой готовой продукции на 45 %;

- снизить производственный брак на 35 %;

- уменьшить затраты на административно-управленческий аппарат на 30%;

- уменьшить страховые запасы на 40 % и площадь складских площадей на 25 %;

- увеличить оборачиваемость средств в расчетах на 30 %;

- увеличить количество поставок точно в срок на 80 %.

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

3.2 Искусство внедрения АСУП

Искусство внедрения АСУП:

- автоматизация предприятия - это долгосрочная инвестиция;

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

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

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

- автоматизация - это «ремонт», сопряженный с временными трудностями и удобствами в перспективе;

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

- нельзя игнорировать предпроектный анализ (сторонние консультанты «свежим» взглядом обнаружат все недостатки и непроизводительные бизнес-процессов);

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

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

- быть готовым к совершенствованию системы по мере развития ИТ и технологий ведения бизнеса;

- помнить о соотношении «80/20»: система автоматизации - это 80 % менеджмент и только 20 % технологии;

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



3.3 Два подхода к автоматизации

До последнего времени существовало два подхода к решению задачи автоматизации предприятия: поэтапная разработка АСУП (MRP/ ERP-систем) собственными силами и внедрение готовой системы.

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

Самостоятельная разработка системы, отвечающей современным требованиям стандарта ERP, предполагает не менее нескольких лет работы коллектива разработчиков и затрат до $1 млн., а иногда и более. Это гораздо дороже приобретения готовых АСУП отечественных разработчиков и соизмеримо со стоимостью внедрения западных систем. При самостоятельной разработке АСУП успех не всегда гарантирован. К тому же предприятие «попадает» в полную зависимость от конкретных разработчиков, поскольку, кроме них, данной системы никто на рынке не знает и при их увольнении оно будет поставлено «на колени». Поэтому в эпоху быстро набирающего темпы аутсорсинга гораздо выгоднее приобретать готовые системы у профессиональных разработчиков, которых на отечественном рынке уже сегодня предостаточно.



3.4 ERP или не-ERP

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

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

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

3.5 Безболезненное внедрение

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

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

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

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

Известно, что работники отечественных предприятий не очень радостно воспринимают любые нововведения. Это вызвано страхом перед нововведениями, консерватизмом, опасением потерять работу или утратить свою незаменимость, показать несостоятельность к самообразованию, а также боязнью увеличивающейся ответственности за свои действия. Поэтому руководитель должен быть готов к тому, что сопротивление сотрудников «на местах» может сорвать или существенно затянуть проект внедрения АСУП.

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

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

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

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

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

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

3.6 Реальность для систем MRPII

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

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

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

Почему справедливо подобное утверждение? В основе системы MRPII лежат принципы формирования заказов, т. е. планирование потребностей в материалах. Это метод управления запасами, который сочетает в себе два принципа:

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

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



Заключение

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

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

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

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

...