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

Шелехметь 2008 149История вопроса

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

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

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

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

fish-388346_640Анализ проекта

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

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

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

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

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

1Предмет оптимизации

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

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

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

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

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

IMG_1687Пилотный модуль

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

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

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

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

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

скачанные файлыПримеры проектов

Приведем только два примера.

В 1992-2000 годах команда СВ участвовала в разработке и развитии автоматизированной системы управления «Завода им. А.М. Тарасова» в г. Самаре. Здесь ключевым модулем стала конструкторская спецификация, которая сразу потянула за собой автоматизацию сбыта (договоры с потребителями), расчет потребности в материалах (снабжение), вопросы организации производства в части незавершенного производства и далее, вплоть до расчета себестоимости продукции.

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

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

Второй пример – модуль «Научные результаты», внедренный в 2013 году в НГПУ. Результаты подробно описаны в соответствующей статье. Здесь следует добавить, что после процесса адаптации к условиям вуза, притирки, освоения и проч., который длился около года, модуль используется целиком и без каких-либо проблем. Планы его расширения также имеются, и мы надеемся, что сможем сообщить о продолжении проекта через какое-то время.

logistikaСистемные методы

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

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

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

Мы работаем над тем, чтобы расширить зону применения компьютерного моделирования на объекты, построенные для реализации дискретного производственного процесса. Об этом можно узнать в статье HiPer технология. Сегодня проблема построения модели объекта кажется еще более актуальной, чем в 90-х. Затраты на решение этой задачи неизмеримо ниже, чем на эксперименты с реальным объектом, а наглядность и полнота позволяют выявить и устранить сотни ошибок до начала реализации проекта.