Главная

Популярная публикация

Научная публикация

Случайная публикация

Обратная связь

ТОР 5 статей:

Методические подходы к анализу финансового состояния предприятия

Проблема периодизации русской литературы ХХ века. Краткая характеристика второй половины ХХ века

Ценовые и неценовые факторы

Характеристика шлифовальных кругов и ее маркировка

Служебные части речи. Предлог. Союз. Частицы

КАТЕГОРИИ:






Адаптируемые системы




Проблема адаптации программного обеспечения АСУП, т. е. при­способления к условиям работы на конкретном предприятии, была осознана с самого начала работ по автоматизации управления.

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

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

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

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

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

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

Поэтому были предложены методики разработки и внедрения программного обеспечения, в основу которых были положены но­вые принципы:

• привлечение пользователей к разработке системы, в том чис­ле и к разработке программного обеспечения;

• прототипирование программного обеспечения;

• совмещение процесса обучения пользователей работе с базо­вой системой создания прототипа программного обеспечения.

Примером может служить подход, предложенный компанией Computer Associates в начале 90-х годов для проектов типа MRPII/ ERP на базе системы CA-CAS.

Прототип ПО АСУП в дальнейшем может использоваться в сле­дующих работах:

• при обучении более широкого круга персонала,

• при опытной эксплуатации,

• при модификации с целью получения окончательного вари­анта ПО.

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

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

• повышение уровня автоматизации проектирования и внедре­ния систем;

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

• сокращение сроков внесения изменений в конфигурацию и параметры системы по мере модернизации производственно­го процесса и управления;

• совмещение типовых решений, проверенных практикой, с ре­шениями, зависящими от конкретных условий предприятия.

Примером одного из многочисленных средств адаптации базо­вых систем является методология Orgware, используемая фирмой BAAN.

Разработка АСУП на предприятии может вестись как «от нуля», так и на основе референционной модели (Reference Model). Референционная модель представляет собой описание облика системы, функций, организационных структур и процессов, типовых в ка- ком-либо смысле (отрасль, тип производства и т. д.). В ней отражают­ся типовые особенности, присущие определенному классу предпри­ятий. Ряд компаний-производителей адаптивных АСУП совместно с крупными консалтинговыми фирмами в течение ряда лет ведет раз­работку референционных моделей для различных отраслей. Суще­ствуют подобные модели для предприятий автомобильной, авиаци­онной и других отраслей. Каждая модель является типовым проект­ным решением, на основе которого можно строить конкретные про­екты. Следует отметить, что адаптации и референционные модели входят в состав многих систем класса MRPII/ERP, что позволяет значительно сократить сроки их внедрения на предприятии.

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

Процесс проектирования системы может включать несколько фаз.

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

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

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

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

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

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

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

Далее выполняются опытная эксплуатация и доработка системы.






Не нашли, что искали? Воспользуйтесь поиском:

vikidalka.ru - 2015-2024 год. Все права принадлежат их авторам! Нарушение авторских прав | Нарушение персональных данных