§ 9.2. Формулирование проблемы

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

Проиллюстрируем основные особенности такой работы, составляющей первые этапы системного анализа, на примере “социотехнических” систем (название взято в кавычки, поскольку системологическая терминология в русском языке еще не совсем устоялась). Особенностью социотехнической системы является то, что люди в ней играют важную роль. Имеются и другие названия таких систем (не совсем синонимичные): “организационные” (что означает в основном состоящие из людей), “автоматизированные” (т.е. состоящие из людей и машин), “человеко-машинные” (обычно так называют систему, состоящую из одного человека и одной машины). Типичными примерами социотехнических систем служат организации типа городской медицинской службы, завода, системы транспорта или связи, экологические системы. Участие в них многих людей, интересы которых различны, делает анализ таких систем особенно сложным. Разумеется, системный анализ применим и к менее сложным системам; при этом многие этапы анализа выполняются проще, быстрее, а иногда и вообще могут быть опущены как уже выполненные ранее; кроме того, уменьшается число итераций, возвращений от последующих этапов к предыдущему, что типично для анализа сложных систем. Чем проще анализируемая система, тем ближе реализуемый алгоритм ее анализа к линейному; чем система сложнее, тем больше циклов реализуется при ее анализе, что, кстати, может служить самостоятельным признаком сложности.

ПРЕВРАЩЕНИЕ ПРОБЛЕМЫ В ПРОБЛЕМАТИКУ

ANALYST аналитик

DIALECTICS диалектика

STAKEHOLDERS заинтересованные стороны

APPLIED прикладной

PROBLEM проблема

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

Итак, первые шаги в системном анализе связаны с формулированием проблемы. Хотя необ-ходимость системного анализа возникает тогда, когда проблема уже не только существует, но и требует решения, когда инициатор системного анализа (“заказчик”, “клиент”) уже сформулировал свою проблему, системный аналитик знает, что первоначальная формулировка – лишь очень приблизительный намек на то, какой именно должна быть действительная рабочая формулировка проблемы. Это относится не только к случаям, когда заказчик лишь обозначает сферу интересов (“Как улучшить работу медицинских учреждений?” или “Как повысить активность и самостоятельность студентов?”), но и когда он достаточно конкретен (“Какой из предложенных проектов принять к исполнению?” или “Какой должна быть модель следующего поколения данного изделия?”) или даже “совсем точен” (“Где в районе разместить новую больницу?”, “Каковы оптимальные параметры такого-то изделия?”).

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

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

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

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

МЕТОДЫ ПОСТРОЕНИЯ ПРОБЛЕМАТИКИ

Приведем некоторые рекомендации, как осуществлять построение проблематики.

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

1) клиента, т.е. того, кто ставит проблему, заказывает и оплачивает системный анализ;

2) лиц, принимающих решения, т.е. тех, от полномочий которых непосредственно зависит решение проблемы;

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

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

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

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

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

Какова бы ни была природа рассматриваемой системы, ее проблематика включает спектр проблем: от допускающих формализацию в виде постановки математических оптимизационных задач (хорошо структурированных, формализуемых, формальных; английские термины – hard problems, well-defined problems до проблем “рыхлых”, слабо структурированных, неформализуемых, выражаемых на естественном языке (английские термины – soft problems, ill-defined problems). Естественно, эти проблемы следует рассматривать по-разному, но в практике системного анализа наблюдается тенденция сводить все проблемы к одному типу. Та же практика показывает, что исследовать “рыхлую” проблему как “жесткую” оптимизационную гораздо опаснее, чем наоборот: если во втором случае мы лишь частично отказываемся от некоторой полезной информации, то в первом привносим ложную информацию, вводя себя и других в заблуждение. Различать “жесткие” и “рыхлые” проблемы в ходе анализа – одно из условий хорошего анализа (но не его гарантия!).

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

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

Summary The most important stage in systems ana-lysis is representation of the problem si-tuation. The client’s statement of the pro-blem is only the beginning. It is then ne-cessary to determine who else will be in-fluenced by the planned changes, and to present the stakeholders’ problems that the changes will cause, in all languages of the configurator. The resulting set of problems – called a problematique or mess – is the starting point for further systems analysis.