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

ЗАДАЧИ КОНТРОЛЯ papka

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

Электротехнический завод

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

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

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

Технический университет

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

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

Региональный кадастр отходов

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

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

Список примеров можно было бы продолжить, но мы показали совсем разные объекты, у которых возникла по сути дела одна и та же проблема.

СРЕДСТВА КОНТРОЛЯ 444

С развитием техники менялись представления о формах и средствах контроля.

Отчеты

Старая форма, в которой следует увидеть подход, повлиявший на все развитие компьютерного мониторинга.

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

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

Пульты

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

OLAP

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

Dashboard

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

Разумеется, есть много других подходов, однако большинство из них страдает одним недостатком — они не имеют универсального решения в плане структуризации информации. Каждый раз требуется отталкиваться от особенностей объекта и создавать уникальную систему. И главное — до сих пор мы группируем данные по принципу происхождения, а не по принципу использования.

СИСТЕМНЫЙ ПОДХОД IMG_3297

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

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

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

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

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

33АНАЛИЗ И СИНТЕЗ

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

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

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

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

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

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

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

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

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

ПРОЕКТ SM-16 clock-70189_640

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

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

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

Ход проекта будет освещаться на этом сайте.