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

IMG_1807Строительство нового объекта

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

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

Рассмотрим задачу строительства нового объекта на примере создания автоматизированных складов. Скажем сразу, что мы занимались только частью этой задачи, а именно – разработкой и внедрением Warehouse Management System (WMS), то есть систем управления складом. Информация о выполнении конкретных проектов приведена на страничке ЛОГИСТИКА.

К моменту, когда проект поступает к разработчику WMS, в нем уже определены все вопросы, связанные с выбором и расстановкой оборудования в соответствии со схемой хранения и движения ресурсов. Задачей ИТ специалиста является обеспечение эффективного управления запасами и потоками ресурсов.

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

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

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

асуОперативное управление ресурсами

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

Особенно актуальной эта задача являлась (и продолжает являться) для машиностроительных предприятий, где часто используется дискретный производственный процесс. Основной задачей системы управления становится MRP или ее современный вариант ERP – Enterprise Resource Planning (планирование ресурсов предприятия). Это требует коренной перестройки всей административной системы, причем не на отдельном полигоне, а в условиях работающего предприятия, которое не может прекратить выпуск продукции.

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

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

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

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

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

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

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

prew_eco2Задачи мониторинга

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

На примере выполнения ЭКОЛОГИЧЕСКИХ ПРОЕКТОВ видно, что имеется достаточно много систем влияния на экологию и защиты экологии, действующих автономно. Конфликты интересов здесь проявляются достаточно отчетливо, необходимость интеграции очевидна, но механизм интеграции не работает.

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

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

Аналогичная задача решается в университетах, где требуется упорядочить сложную систему развития отдельных научных коллективов и направлений (см. статью СИСТЕМЫ ВУЗОВ). Как первый шаг может быть рекомендовано внедрение системы РЕЙТИНГА КАФЕДР, который затем начинает развиваться путем совершенствования показателей.

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