Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь КАТЕГОРИИ: АрхеологияБиология Генетика География Информатика История Логика Маркетинг Математика Менеджмент Механика Педагогика Религия Социология Технологии Физика Философия Финансы Химия Экология ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
Классификация систем автоматизации управления
ПРЕДПРИЯТИЕМ Заказные / уникальные системы Под заказными или уникальными системами обычно понимаются системы, создаваемые для конкретного предприятия, не имеющие аналогов и не подлежащие в дальнейшем тиражированию. Подобные системы используются либо для автоматизации деятельности предприятий с уникальными характеристиками, либо для решения крайне ограниченного круга специальных задам. В основном подобные системы применяются в органах государственного управления, образования, здравоохранения, военных организациях. Заказные системы, как правило, либо вообще не имеют прототипов, либо использование прототипа требует значительных его изменений, имеющих качественный характер. В этом плане разработка заказной системы по существу является НИОКР. Как любые НИОКР, она характеризуется повышенным риском в плане получения требуемых результатов. Для снижения рисков и расходов на разработку целесообразно использовать апробированную на практике методику. Желательно, чтобы в состав методики входили следующие элементы: • модель технологического процесса (последовательность технологических операций, требования к входной и выходной информации и результатам); • модель процесса управления самим технологическим процессом (этапы, процессы управления качеством, результатами, требования к квалификации специалистов); • инструментальные средства, используемые при разработке. Одним из примеров такой методики является комплексное использование подхода CDM Advantage™, метода управления проектами PJM и CASE-средства Designer/2000 в качестве инструментального средства корпорации Oracle. Адаптируемые системы Проблема адаптации программного обеспечения АСУП, т. е. приспособления к условиям работы на конкретном предприятии, была осознана с самого начала работ по автоматизации управления. Содержание и методы адаптации эволюционировали вместе с методологией создания и внедрения систем. Суть проблемы в том, что в конечном итоге каждая АСУП уникальна, но вместе с тем ей присущи и общие, типовые свойства. Любая подсистема программного обеспечения отображает обе эти стороны АСУП. В технологическом смысле адаптация программного обеспечения АСУП — это переход от базовой системы, отображающей типовые свойства системы, к окончательному решению, приспособленному для работы в данной АСУП.
Требования к адаптации и сложность их реализации существенно зависят от проблемной области, масштабов системы, степени соотношения между формализованным и неформализованным при решении задач управления. Даже первые программы, решавшие отдельные задачи управления, создавались с учетом необходимости их настройки по параметрам. Поскольку на раннем этапе остро стоял вопрос обеспечения вычислительными мощностями, то главное внимание уделялось настройке потребностей в оперативной памяти, способам остановки при решении задач оптимизации, управлению программой для обхода программных модулей, не используемых в конкретном расчете. С появлением типовых решений в виде пакетов прикладных программ (ППП) появилась необходимость в специальных процедурах предварительной генерации. Процедуры охватывали параметры, которые определяли режим функционирования программного обеспечения, требования к информационному обеспечению, условия подключения и использования внешних программ. Применение ППП как базовых систем привело к увеличению формализованной составляющей в системе управления предприятием. Усложнилась и адаптация систем к условиям предприятия. Появились подразделения эксплуатации программного обеспечения, занимавшиеся в том числе и вопросами адаптации программных систем. Стало очевидно, что адаптация в АСУП является не только программно-технической, но и организационной проблемой. Интерактивные системы, сделавшие управленцев всех уровней непосредственными пользователями вычислительных систем, привели и к новому пониманию проблемы адаптации. Глубинные причины были прежними — смещение соотношения между формализованным и неформализованным в сторону формализации процесса управления. Основная сложность заключалась в том, что формализация затронула не только типовые, но и уникальные функциональности в системе управления предприятием. Из всего множества трудностей, проявившихся на данном этапе развития АСУП, следует остановиться на двух. Первая — организация дружественного интерфейса между пользователем и вычислительной средой. В ходе развития систем управления в арсенал средств организации интерфейса вошли меню различного вида, электронные доски и панели, диаграммы типа диаграмм Черноффа и Иши-кавы, графика и многое другое. Вторая трудность носила системный характер. Прежний подход — настройка системы силами консультантов практически без участия управленцев — стал невозможен. Выяснилось, что во многих случаях оказывается неэффективной организация внедрения, при которой будущие пользователи сначала формулируют требования к системе с учетом специфики предприятия во всех деталях, а затем консультанты настраивают систему на условия применения. Существует ряд причин подобной неэффективности. Во-первых, как правило, управленцы-практики не владеют методологиями системного анализа. Во-вторых, объем информации, касающейся деталей в организации управления на конкретном предприятии, оказывается слишком велик. В-третьих, не всегда эта информация оказывается полезной и консультантам в силу ее «одноразового» характера. В-четвертых, при такой организации трудно реализовать принцип новых задач, для этого в процессе внедрения потребовались бы дополнительные итерации.
Поэтому были предложены методики разработки и внедрения программного обеспечения, в основу которых были положены новые принципы: • привлечение пользователей к разработке системы, в том числе и к разработке программного обеспечения; • прототипирование программного обеспечения; • совмещение процесса обучения пользователей работе с базовой системой создания прототипа программного обеспечения. • при обучении более широкого круга персонала, • при опытной эксплуатации, • при модификации с целью получения окончательного варианта ПО. Такой подход позволил в определенной степени решить проблему адаптации системы управления и в динамике, поскольку работники предприятия в ходе создания прототипа приобретали навыки работы со средствами проектирования и модификации системы. Дальнейшее развитие методов и средств адаптации базовых систем направлено на достижение следующих целей: • повышение уровня автоматизации проектирования и внедрения систем; • обеспечение непрерывного управления конфигурацией и параметрами системы на всех стадиях ее жизненного цикла; • сокращение сроков внесения изменений в конфигурацию и параметры системы по мере модернизации производственного процесса и управления; • совмещение типовых решений, проверенных практикой, с решениями, зависящими от конкретных условий предприятия. Примером одного из многочисленных средств адаптации базовых систем является методология Orgware, используемая фирмой BAAN. Разработка АСУП на предприятии может вестись как «от нуля», так и на основе референционной модели (Ref erence Model). Референционная модель представляет собой описание облика системы, функций, организационных структур и процессов, типовых в каком-либо смысле (отрасль, тип производства и т. д.). В ней отражаются типовые особенности, присущие определенному классу предприятий. Ряд компаний-производителей адаптивных АСУП совместно с крупными консалтинговыми фирмами в течение ряда лет ведет разработку референционных моделей для различных отраслей. Существуют подобные модели для предприятий автомобильной, авиационной и других отраслей. Каждая модель является типовым проектным решением, на основе которого можно строить конкретные проекты. Следует отметить, что адаптации и референционные модели входят в состав многих систем класса MRPII/ERP, что позволяет значительно сократить сроки их внедрения на предприятии.
Если в распоряжении предприятия нет референционной модели, то модель ее уровня надо создавать в процессе проектирования как исходную. На основе исходной модели затем происходит проектирование, уточнение и детализация системы управления. Референционная модель в начале работ по автоматизации управления предприятием может представлять собой описание существующей системы и служить, таким образом, точкой отсчета, с которой начинаются работы по совершенствованию системы управления. Процесс проектирования системы может включать несколько фаз. Результаты первой фазы: границы действия будущей системы и концептуальная бизнес-модель, которая отражает в укрупненном виде функциональную структуру системы управления и связки функций управления для различных видов заказов, проходящих через систему. В ходе второй фазы создается и документируется в репозитарии референционная бизнес-модель. Как правило, референционная модель включает следующие компоненты: • иерархию бизнес-функций, представляющую собой нисходящую иерархическую структуру, описывающую в укрупненном виде функциональную структуру будущей системы. При этом для нижних элементов структуры допускается задание нескольких вариантов реализации; • модели бизнес-процессов. Это более глубокие модели, показывающие, как должны реализоваться функции. Внешне они напоминают традиционные блок-схемы и описывают последовательность элементарных действий, которые могут быть выполнены системой, другими приложениями, ручными действиями, бизнес-процессами более глубокого уровня; • модель организационной структуры, которая описывает структуру организации, отношения между подразделениями и людьми и роли, предписываемые управленцам. На следующей фазе создается проектная модель предприятия (Project Model), которая является развитием и уточнением функциональной структуры для конкретного предприятия. Она может быть создана и минуя референционную модель, но такой подход не является эффективным для сложных проектов. Заключительная фаза — привязка проектной модели к ролям, заданным детализированной моделью организационной структуры, к функциям системы и техническим средствам. В результате создается комплексная конфигурация программного и организационного обеспечения, технических средств. Далее выполняются опытная эксплуатация и доработка системы.
|
|||||||
Последнее изменение этой страницы: 2022-09-03; просмотров: 23; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.145.173.112 (0.014 с.) |