Беру и не делаю. Почему не работаю по руководству Системное мышление

Спойлер

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

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

Какие проблемы?

Неадекватная привязка к прогрессу в aisystant

Обнаружила сильную зависимость от прогресса в системе: если не прочитываешь подраздел, прогресс теряется.
При этом выполнение заданий часто занимает несколько дней, и ещё надо себя заставить их сделать.
Получается парадокс: вроде как есть «уважительная причина» — прочитать подраздел, чтобы не потерять прогресс, а задание — «поделать потом, если останется время» (ха-ха).

Разрыв между “берёшь и делаешь” и реальной практикой

Продолжала читать сообщения в чате и посты в клубе. Там часто звучит «берёшь и делаешь».
С руководством по рациональной работе так и было — и результаты были видны сразу.
Но с системным мышлением постоянно хотелось отложить применение…

Что включило фокус на эти проблемы

И всё это происходило ровно в тот момент, когда мне пришлось на собственной шкуре столкнуться с ошибками, которые не смогли предусмотреть исполнители/создатели/команды при создании целевой системы — больницы, в которой я оказалась пациентом.

Капремонт был только что завершён, всё чистое и свежее, но:

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

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

Где мы находимся в цепочке создания таких систем

Целевыми системами нашей организации (экспертизы) являются больницы, школы, дороги и т.п.

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

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

А я где в графе?

Мое место в графе ещё дальше, наверное, меня можно назвать инженером внутренней платформы, хотя все ещё есть сомнения:

  • участвовала в разработке услуги, сейчас продолжаю заниматься её развитием
  • занималась внедрением таск-трекера (надоело вести командные задачи в гугл-таблице). Руководство по РР рекомендую - перепроходила в начале этого года - многое оттуда применила. Сейчас осуществляю поддержку и по возможности развитие
  • появилась необходимость в ботах для автоматизации новых процессов - начала писать их (обожаю GPT)
  • ещё должна заниматься развитием BIM в экспертизе, но на него не остается времени

Почему же не использую руководство в работе?

С прогрессом в aisystent разобралась - просто не захожу в ЛК.

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

Нужно идти ещё ближе к истокам:

  • как объекты попадают в АИП?
  • кто в них заинтересован?
  • кто будет пользоваться построенными объектами?
  • кто будет обслуживать?

Это всё важно для концепции использования.
Поначалу я пыталась вытащить ответы из ТЗ — но они настолько убогие, что даже увязать интересы участников сложно.
Мы просто не можем «дотянуться» до них со своего узла графа — получается игра в глухие телефоны.
Поэтому кажется, что выполнение заданий не принесет пользы.

Что можно с этим сделать?

В больнице я думала о том, что всё зря и пошло оно всё лесом…

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

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

И в следующем году хочу снова сделать заход на включение в процесс создания концепции использования зданий и сооружений в рамках услуги сопровождения.

3 лайка

Вам скорейшего выздоровления! Надеюсь все обошлось!

Возможно тут неверно определена целевая.

Дальше вы описываете потребности пациента - нет розеток, питьевой воды и т.п. значит не учтены роли при создании/ремонте. Заплатили за ремонт, но не учли как будет использоваться больница и кто будет платить больнице и за что.

Поделюсь своим подходом - честно скажу я немного хитрю. Я иду по руководству почти каждый день читаю, иногда удается уделять только 10-15 минут (крошки времени), но акцент больше на ритме. Когда дохожу до заданий, которые сразу могу сделать, делаю, а которые требуют большего времени, оставляю. Иногда к оставленным возвращаюсь вообще в самом конце руководства, иногда в тех долги/черновики и возвращаюсь уже во время прохождения других руководств. Да, это не совсем так, как рекомендовано, но тем не менее добрался до инженерии личности и поглядываю в системную инженерию и интеллект-стек.

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

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

1 лайк

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

1 лайк

С ритмом проблем нет. В обычном режиме каждый день уделяю по часу МИМ и по моему календарю активности может график отпусков сверять - там часто оказываюсь вне зоны доступа.

А вот с заданиями стала филонить.

У меня на втором проходе многое встает на свои места. Может быть и в этом тоже проблема, кажется что и так всё понятно, зачем это описывать :grin: - на те же грабли…

1 лайк

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

Выздоровевший пациент - это скорее надсистема. Работа у нас ведется всё-таки над описаниями зданий и сооружений, поэтому и считаю, что для нашей организации целевыми системами будут они.

2 лайка

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

P.S. МГЭ? МОГЭ? или другой регион какой? (интересно просто)

Соглашусь, у меня дребезжало, но не вытащила это до конца. Всё-таки отношение создания, а не композиции между больницей и пациентом.

Пермский край

о, был там два года назад, в вашей экспертизе, вот с этим(извините за оффтоп..))

1 лайк

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

так же, догадка, что есть там промежуточные системные уровни(даже если думать про больницу), как раз про палату, операционную и тд.

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

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

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

Зачем: от понимания, интересов и предочтений вокруг целевой (верно выбранной), легче учитывать что там нам в наших учитывать, нюансы всплывают, которые вероятно неучли и в итоге этих неучтенностей - система менее успешна(мнее удовлетворяет предпочтения ролей).

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

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

Что радует, что возможно вижу то, как могу связать свой разговор со своей командой/фирмой по связке, отталкиваясь от целевой аргументировать, строить связь и к "частям” аптек, учитывая и интересы ролей, которые рядом с нашей системой, нашей клиентурой.


заметка: рассматривания “с конца”, с момента эксплуатации целевой полезно - прям время самой эксплуатации, и при этом учитывать, что там разные ветки системы создания, в них можем не участвовать, но полезно учесть, заметить.

заметка1: целевые обнаруживаются зачем: в основном, чтоб потом от нее оттолкнуться и рассмотреть роли и их интересы, предпочтения. Если промажем с целевой, какие-то интересы и предпочтения неучтем - будет неуспех. А это итоговое стремление.

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

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

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

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

1 лайк