Вноябре прошлого года мы опубликовали статью "Время простых вопросов", посвященную организации рынка сложных программных систем управления (см. "Э-У" N 42 от 10.11.03). Затем в целой серии статей мы много говорили о проблемах науки управления и прочих философиях. Пора переходить к конкретным предложениям. Представим новые подходы к разработке, внедрению и развитию информационных систем (ИС) управления, которые разработаны в России и активно воплощаются в конкретные технологии и продукты.

AS-IS1

"Как есть" - согласно распространенной сегодня методологии, первая стадия анализа объекта, на которой описывается его текущее состояние.

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

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

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

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

Как правило, пока таким методом полученная модель воплощается в программу, бизнес-процессы (как наименее стабильная сторона бытия) меняются иной раз до такой степени, что ИС теряет адекватность уже до первой своей "примерки". Что же делать? Опять запускать цикл хождений бригад консультантов по заводоуправлению? Но кто даст гарантию, что после нового моделирования не произойдет то же, что и после старого? И обычно принимается простое решение: сколь деньжищ уж перевели, давайте, ребята, как есть...

Альтернативой "водопаду" была выдвинута концепция под названием "экстремальное программирование". Она основана на признании того, что раз нельзя адекватно представить объект комплексной автоматизации, то и... не надо. А нужно, руководствуясь житейской мудростью "глаза боятся - руки делают", смело браться за первую понятную задачу. Быстро ее решать, потом брать другую, третью, десятую...Словом, действовать подобно повару Ноздрева, который бросал в суп все, что под руку попадет, здраво рассуждая: "Было бы горячо, а вкус, верно, какой-то да выйдет". Конечно, созданные локальные системы будут слабо согласованы, но и тут нельзя терять экстремальности, а смело дописывать недостающее, мирить противоречащее, усмирять бунтующее и, главное, не терять темпа, а быть на острие жизни. Легко заметить, что этот метод с его сумбурностью и радикализмом - некий антипод размеренному и неповоротливому "водопаду".

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

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

TO-BE2

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

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

Разработчикам ИС также необходимо иметь полные и непротиворечивые модели своих объектов - предприятий. Чем эти модели отличаются от тех, что создаются обычными методами? В обычном случае объект автоматизации просто описывается "как есть", поэтому полученные таким образом модели можно назвать описательными. Но согласно аксиомам гносеологии (науки о познании) любой, даже самый обычный предмет может быть описан и представлен бесчисленным числом способов - все зависит от цели анализа и точки зрения наблюдателя. Кроме того, предприятие, согласно описательному методу, моделируется не только с разных точек зрения (например, с позиции финансиста или технолога или специалиста по качеству и т.д.), но и в основном опираясь на "показания" сотрудников предприятия, что еще больше запутывает ситуацию. Отсюда основные проблемы описательного подхода: множество несводимых друг к другу моделей одного и того же объекта, при довольно низком их качестве и необходимость для каждой новой задачи разрабатывать новую модель (с другой "точки зрения" на объект). Отсюда необходимость утомительного, дорогого и сомнительного с точки зрения результата этапа - моделирования бизнес-процессов.

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

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

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

Следующий шаг семантического метода - понять логику развертывания из единого смыслового ядра таких форм складов, как сельмаг, морской терминал или любой другой. Это происходит путем добавления к первоначальному "гену" новых, но столь же однозначно определяемых смысловых форм. Например, к общей модели сельмага добавляется модель прилавка, базовый смысл которого одинаков и для сельмага, и для расчетного узла супермаркета, и для кассы кинотеатра: обмен N количества товара А на Х количество валюты вида В. Добавляя к семантическому ядру понятия "склад" более конкретные смысловые элементы, мы придем к таким моделям, как "абстрактный сельмаг" или "абстрактный портовый терминал", которые адекватно опишут логику работы любого сельмага и терминала на свете. Имея такого рода модели, мы можем, увидев в деревне нечто похожее на магазин, почти без хлопот а) определить, что это именно он и есть, б) выявить всю основную логику его работы. И даже если работа конкретного сельмага будет как-то отличаться от базового "шаблона", эти отличия очень легко понимаются благодаря их смысловой привязке к логике исходной модели.

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

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

Возникает вопрос: по каким методологиям можно познавать смыслы вещей? Где этому учат? Очень хорошо на этот счет написал известный российский философ управления Сергей Чернышев: "В основе всякого организационного проекта должна лежать идеальная модель организации, которую мудрецы прозревают на небесах". Да, именно так: смыслы прозреваются, благодаря... кто может сказать верно, благодаря чему и как они прозреваются?.. Они просто как-то прозреваются - в молитве ли, в медитации ли, в хмельном сне... Кто мог предвидеть прозрения Менделеева и другие великие открытия? И потому семантическое моделирование плохо поддается регламентации, и нельзя представить, чтобы клиент сделал заказ, скажем, на "познание смыслов работы овощного склада путем созерцательных размышлений". Но иного пути для познания сложных и изменчивых объектов, каковыми являются сегодня все более или менее крупные организации, нет. Именно разработка системы смысловых моделей и понимание непротиворечивой логики развертывания их генотипа - ключевое направление развития отрасли разработки комплексных систем управления.

Для чего все это

Использование семантических моделей предприятия и его ИС приводит к поразительным результатам. Радикально изменяется процесс моделирования объекта и проектирования ИС, ибо нет необходимости каждый раз "открывать" устройство предприятия заново. Имея смысловой ключ к любым типам объектов, можно очень быстро их идентифицировать и понять логику работы. Что есть в очередном объекте нового - это всегда лишь второстепенные элементы, добавления к базовой модели. Они очень быстро, в несколько часов (максимум - дней), фиксируются и добавляются к исходному шаблону как его развитие. Есть реальный опыт: создание по новой методологии ERP-системы с полным функционалом занимает в сотни раз меньше времени, чем на это требуется по обычной методе. Это значит, что даже заказную разработку такой системы "с нуля" можно сделать быстрее и качественнее, чем внедрить коробочное решение.

Исходные модели - это модели жизненных смыслов, значит, они понятны всем, кто так или иначе связан с той реальностью, которую они описывают: и начальникам, и подчиненным, и разработчикам. Люди разных профессий начинают говорить на одном языке, а это значит, что они одинаково видят мир, хотя бы в той его части, которая описывается в семантических моделях. При этом все участники процесса всегда будут понимать друг друга, какие бы изменения ни случились на предприятии, ибо все изменения будут только развитием исходных моделей, а значит, развитием всем понятного протоязыка. Поэтому и развитие логики управления, логики, информационных систем и программного инструментария не представляет проблем. Например, если есть семантическая модель любого производственного процесса, то предприятие, имеющее, скажем, дискретный его тип, просто достраивает к исходной модели элементы, специфические именно для дискретной логики, и получает ИС управления любым дискретным производством. Организация последнего тоже отличается от отрасли к отрасли: тогда к полученной на последнем шаге модели добавляется специфика конкретной отрасли и получается модель управления любым производством данной отрасли. Ясно, что предприятие, осваивающее производство с иным исходным "геном", чем у дискретного, просто берет базовую модель производственной логики и достраивает ее до нужного варианта. Надо ли говорить, какой огромный спектр проблем в создании и развитии ИС решает такой метод?

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

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