Работа с возможностями требует выделения системных уровней. На шаге первом нужно определить целевую систему, которая «генерирует» изменения в реальном физическом мире. На втором шаге – определить надсистему, потому что в ней находятся заказчики, которые заплатят за генерируемое изменение (функцию), потребности которых целевая система должна удовлетворять. И только на третьем шаге вы обращаетесь к системе обеспечения. Если вам нужно здоровье как функция системы «здоровая спина», то следующий шаг – определить, в каких ситуациях у вас болит спина, чтобы устранять проблемы конкретно в них, и только потом думать, как вы будете этого добиваться. Если вам нужна функция «общаться с китайцами и понимать друг друга», то следующий шаг – определить, в каких ситуациях вы будете с ними общаться – будет ли это бытовое общение, бизнес, обучение и т.п., и только потом выстраивать программу курса по китайскому (систему обеспечения вас, общающегося на китайском).
Без выделения системных уровней вам будет тяжело понять, как сделать продукт, который решает проблему пользователей / удовлетворяет потребности внешних ролей. Вы будете тыкаться наугад, пытаться изучить «весь китайский сразу», хотя вам нужно только деловое письмо; или будете беспорядочно нанимать людей, чтобы они «сделали хорошо» компании вместо того, чтобы понять, что вы делаете, для кого и в ходе стратегирования определить, как это должно быть сделано.
Выделение системных уровней важно для стратегирования. Когда вы начинаете стратегировать, уже должны быть определены целевая система и надсистема, а также система обеспечения. В личных проектах выделять системные уровни обычно проще, поскольку там чаще всего достаточно определить целевую систему, надсистему и систему обеспечения. Например, целевая система «поездка в Китай для языковой практики», надсистема – «ситуации бытового общения с китайцами», система обеспечения – «обучение китайскому по составленной для поездке программе». В личных системах проблема чаще возникает с собственными ролями, поскольку «я» выступаю в нескольких ролях:
- как заказчик системы «поездка в Китай» я хочу язык для общения;
- как предприниматель выбираю языковой курс / индивидуальные уроки с преподавателем, выделяю время и средства;
- как инженер составляю или корректирую программу обучения для поездки;
- как обучающийся следую программе и изучаю отдельные уроки;
- как менеджер отслеживаю сроки обучения, пропуски и т.п.
Когда вы имеете дело с компаниями, выделять роли обычно легче, а вот с системными уровнями все сложнее, поскольку «наша система» может не совпадать с «целевой». В сложных проектах «ваша система» может находиться в составе системы обеспечения или в цепочке систем обеспечения. Например, разработчик MS Teams для ШСМ мог бы сказать, что целевая система – это MS Teams, но это было бы неверно. Для ШСМ целевой системой является измененный кусок мозга студента или студент с поставленными практиками собранности, который может применить знания в разных жизненных ситуациях (надсистеме). В системе обеспечения студента с точки зрения ШСМ находятся курсы, при помощи которых «меняем» кусок мозга/картины мира, например, курс «Введение в системное мышление». И только в составе системы обеспечения курса «Введения в системное мышление»[1] находится MS Teams для ШСМ.
Если ваша компания поставляет данные / делает платформу, то она тоже находится в системе обеспечения системы обеспечения минимум на 1-2 уровня вниз от целевой системы. Это необходимо понимать, поскольку для успешной работы «вашей системы» нужно, чтобы целевая система была успешна. Если мышление студентов курса «Введение в системное мышление» не будет меняться, если они не смогут (при условии, что они прикладывают усилия) поставить практики и что-то поменять в жизни, то и MS Teams не будет нужен. Этот же принцип действует в отношении вашей работы: если вы делаете классно спроектированный, удобный и недорогой модуль, который используется в неуспешном продукте, то вашу работу оценят ниже, чем оценили бы точно такую же работу в успешном продукте.
Цепочки системных уровней можно изобразить так:
Вы определяете, какого изменения вы бы хотели добиться в физическом мире, и изучаете потребности и интересы внешних ролей, которые (по вашему мнению) за такое изменение / функцию заплатят. После этого вы меняете целевую систему и/или отбираете потребности и интересы внешних ролей, которые будете удовлетворять. Вы не бросаетесь удовлетворить абсолютно все потребности – на это банально не хватит ресурсов, а собираете определенный набор, который вам «по зубам». Например, вы составляете список проблем со здоровьем, и понемногу начинаете разбираться с каждой из них, потому что взмахнуть волшебной палочкой и резко стать абсолютно здоровым, к сожалению, невозможно. Или определяете, что вам китайский нужен в первую очередь для общения с деловыми партнерами, а не для развлекательной поездки, и в первую очередь выделяете время и средства на прокачку бизнес-языка.
Дальше вы переформулируете потребности в требования к системе, и здесь тоже вводите ограничения, потому что не все требования можно в рамках существующих ограничений удовлетворить. Например, невозможно за один месяц выучить весь деловой китайский, но подготовиться к одной-двум встречам так, чтобы продемонстрировать базовые знания языка и делового этикета, вполне реально. Если вы производите дешевую одежду, то требование использовать дорогие ткани в производстве попросту принесет вам убыток, вы быстро прогорите.
Потребности и интересы ролей задают контекст и ограничения по всей цепочке систем обеспечения. Понимать всю цепочку системы обеспечения целевой вплоть до «вашей» необходимо, но подробно изучать потребности и интересы всех в цепочке по умолчанию нет необходимости. Нужно понимать целевую систему и риски, которые могут грозить вам в связи с изменениями в ней. Например, если ваша компания производит детали для двигателя внутреннего сгорания, то в ближайшие 10-15 лет вам грозит значительное снижение прибыли из-за внедрения электромобилей. Перестанут покупать автомобили с ДВС – запчасти тоже не будут нужны, и нужно понимать, что вы будете делать, когда этот момент настанет. Понимать нужно уже сейчас или хотя бы в ближайшие пару лет, потому что, когда момент настанет и от автомобилей откажутся, вы можете не успеть перестроиться и выжить.
Если подобных рисков нет или они пока неясны, то нужно как минимум хорошо понимать потребности интересы «вашей системы» и на один уровень выше и ниже. Остальное рассматривать по мере необходимости, и второй шаг после определения уровня, от которого отталкиваться, делать вверх по системным уровням, а не вниз.
Подробнее о часто встречающихся ошибках в системном разбиении можно прочитать в блоге ШСМ[2].
- [1] То есть в составе системы обеспечения системы обеспечения.
- [2] https://blog.system-school.ru/2020/11/20/system-breakdown-mistakes/
Источник: учебник/онлайн-курс «Введение в системное мышление»