2. Методы построения проблематики

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

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

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

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

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

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

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

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

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

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

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

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