Russia, Sank-Petersburg, SPbGTU

The conventional "classic model" approach to organization of control of companies occasionally appears unacceptable in practice because of various limitations, inevitably introduced at simulation. It becomes particularly obvious for organization of control over systems (companies) with high situational dynamics. For such cases the development of instrumental control system is expedient.

Россия, Санкт-Петербург, СПбГТУ

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

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

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

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

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

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

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

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

Так же целесообразно отказаться от сокращений наименований и всякой “кодировки”, кроме уже принятых в практике и всем знакомых. Это на самом деле “особенность” нашего подхода, обычно “автоматизаторы” стремятся все “сократить и улучшить” и это обычно приносит много вреда. Cache’ – технология позволяет легко обойтись без “улучшений”. После освоения первой очереди системы возможно многое придется изменить, но что и как менять лучше и проще всего покажет именно практика, а не сторонний аналитик. Теперь о составе объектов.

Обычно в АСУ на месте “управления” присутствует в нашей терминологии один объект, состоящий из директора с одним методом [утверждаю]. Вот именно этот объект целесообразно существенно расширить, сделать составным, включив в него следующее.

1. Декларативный объект, содержащий полную подборку учредительных, юридических и нормативно-правовых документов. В начальный период достаточно просто описать такой объект (всего 12 строчек кода), но с начала эксплуатации загрузить хотя бы для тренировки персонала.
2. Динамический раскрываемый объект, представляющий собой “фотографию”, точнее “мультфильм” прохождения заказов и взаимодействия всех подразделений. Этот объект мы достаточно подробно разобрали выше, в разделе о типах объектов. кроме того, добавить пустой объект с демонами “часы” и “ускоренные часы”. Назовем это все вместе объект-“модель”.
3. Объект “архив моделей”, сформированный по следующему принципу. Запоминается, например, с периодичностью раз в месяц та “модель” (состояние объекта “модель”), по которой фактически происходило выполнение профинплана. Архив сохраняется до конца текущего года и на следующий год. Он служит “скелетом” для составления профинплана на следующий год.

Все остальные подразделения, точнее объекты целесообразно представить как привычные папки с привычными документами прохождения заказов. Не нарушая общих принципов “невмешательства в существующую организацию производственного процесса, а только лишь по возможности точно копируя его управленческую сторону с самого начала целесообразно существенно дополнить объект “плановый отдел”. Разместим “рядом” с ним объект “круглый стол”, являющийся фактически копией объекта “модель”. Тогда к “модели” будут иметь доступ фактически все подразделения, т.е. каждый может видеть “как идут дела в целом”. Использовать саму “модель” из объекта “управление” для этой цели нельзя, так как нарушится дисциплина доступа.

Рассмотрим главную особенность функционирования системы - использование объекта “модель”.

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

Управляющий высшего звена, например плановик (или зам. по производству) может активировать объект “модель” и скорректировать ее с учетом имеющегося запаса ресурсов и реальных параметров. Затем нужно запустить “модель”, но с “ускоренными часами” и просто увидеть как будут проходить заказы, будет ли срыв сроков и когда.

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

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

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

Рассмотрим некоторые аспекты функционирования построенной системы с позиции формализмов теории управления и имитационного моделирования. Что же фактически происходит при использовании объекта “модель”?

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

В составе объекта “модель” должен быть метод “поставить задачу”, заключающийся в следующем.

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

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

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

Подход объемного планирования вполне допустим и корректен по двум причинам.

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

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

где - максимальное количество операций

в технологическом цикле ИП;

- количество заказов в пакете;

Pi - ресурс по операции;

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

P_Pi - резерв ресурса по операции;

P_Di - ресурс на дополнительный заказ;

P_Фi - фактически использованный ресурс на пакет заказов.

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

• второе соотношение из приведенной системы (1) никогда не “записывается” и не “решается”, напомним, что объект “модель” периодически сам отслеживает состояние ресурсов;
• не надо заботиться о корректности системы неравенств, если вновь устанавливаемый заказ содержит не все операции. Напомним: в “классическом” исполнении это будет означать, что часть системы неравенств просто не определена и надо употреблять весьма сложные программистские приемы, чтобы все было корректно;
• если новый заказ невозможно установить в план, то при “классическом программировании с уравнениями” модель может только сигнализировать о неразрешимости задачи и не существует единой формы программ, единого приема для разрешения этой коллизии. Обычно ставят задачу “с подвижными ограничениями”, т.е. размерность системы неравенств увеличивается как минимум вдвое, а получив решение еще предстоит разобраться что это означает и что с этим делать. Наша “модель” просто показывает на экране по какому ресурсу, когда и насколько произошел выход за ограничения.

Теперь во-вторых, вторая причина по которой употребление нашей “модели” корректно. Все манипуляции с объектом “модель” по установке заказа и получении варианта плана вряд ли займут времени больше 3-5 минут. Это означает, что именно состояние производства наблюдаемо в любой момент и именно с теми параметрами, которые есть на самом деле, а не “придуманы”.

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

M {П(P_IJ, F₁(P_ФIJ), F₂(P_DIJ), F₃(P_PIJ)) ≥ 0} (2)

где П – полином общего вида;

Р – общий ресурс;

Р_Ф - фактически задействованный ресурс;

Р_D - дополнительный ресурс;

Р_Р - резервный ресурс;

F₁, F₂, F₃ – некоторые кусочно-гладкие функции с конечным числом конечных разрывов.

Т.е. фактически это совокупность всех физически реализуемых моделей нелинейного программирования общего вида с одной оговоркой: – мы не вычисляем функциональные зависимости F₁, F₂, F_{3 ,} не пытаемся угадать, а просто присваиваем значения, снятые непосредственно с состояния производства в точке запуска модели (в момент ее запуска).

Но здесь вовсе нет и намека на претензию, что мы изобрели аппарат, “решающий все задачи нелинейного программирования”. Надо строить инструмент, который позволит строить разные модели, а все остальное зависит от того, насколько:

• полно и удобно для пользования реализован объект “модель” и экранные представления;
• управляющий менеджер понимает свое производство и научился использовать “модель”.

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

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

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

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

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

Да и будет ли какой руководитель постоянно держать свое предприятие в режиме “выжимания последней капли”? А то, что “постоянно натыкается на ограничения” – это природа самого объекта, открытой системы в режиме “больших возмущений”, когда внешние воздействия постоянно “сбрасывают” систему с гомеокинетического плато. Управление же устроено таким образом, чтобы максимально оперативно уловить эту ситуацию и найти режим восстановления на плато, даже если это будет уже другое плато, другой план.

Одна из особенностей видна уже из самого изложения проекта управления для ИП, он “очень маленький” если сравнивать, например, с проектами АСУ в сотни и тысячи страниц. Но, с другой стороны, кажется исходно все ясно, остальное адекватно можно оценить и сделать лишь при реализации. А разве не к этому стремится все развитие науки и технологии? Тщательный и всесторонний анализ объекта, столь же тщательный подбор адекватного инструмента, короткая и ясная логика использования инструмента и, далее, надо приступать к делу. А пухлые проекты прошлых десятилетий – это всего лишь следствие неадекватной теории, плохой техники и неразвитых информационных технологий.

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

При этом возможно сильно упростится и станет более однородной сама логическая структура проекта. В частности станет ненужным выделение многих логических типов объектов, в пределе все их можно будет объединить в модели ТММД (напомним это “ядро” Cache’, Транзакционная Многомерная Модель Данных). Однако для текущего проекта, для того чтобы более адекватно отобразить “живой” объект на логические структуры, выделение логических типов объектов представляется целесообразным.

Далее, мы очень мало обсуждали проблему интерфейса, проблему экранных форм. Но здесь нет смысла в изобретении “специальных машинных форм”. Более того, “априорное изобретательство” скорее всего окажется вредным. Точнее и лучше все определить на практике, взяв за “стартовый вариант” привычные формы документов.

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

Надо отдавать себе отчет в том, что только в случае “целевой направленности на получение заранее предписанного результата”, т.е. в случае “классических АСУ” положительным результатом является достижение “предварительно придуманного”. Технология “вечно изменяющихся” систем Cache’ не предусматривает этапов внедрения, предусматривается непрерывное по ходу эксплуатации совершенствование системы. Фактически, в альтернативу АСУ, мы предлагаем здесь процедуру формирования системы “на ходу и по мере изменяющихся потребностей”, т.е. тот самый инструментальный подход, который изначально и задумано было получить.

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

Однако и в таком усеченном варианте система гарантированно даст значительный эффект.

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

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

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

Литература

1. Иванов А.В. Информационные управленческие технологии издательской деятельности. СПб., Изд. СПбГТУ, 2000 г.