Анатолий Левенчук - Системное мышление

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

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

И индивиды какого-то предприятия, и индивиды какого-то отдельного оргпроцесса 64 64 Мы вслед за ISO 29148 рекомендуем говорить не «бизнес-процессы» (business process), а «организационные процессы» (organizational processes), оргпроцессы. тем самым становятся вполне «физичными», неабстрактными, имеющими пространственно-временную протяжённость, их легко представить. Для начала нужно просто перечислить входящие в оргпроцесс физические объекты-индивиды – и сразу станет понятно, одинаково ли вы понимаете этот оргпроцесс с другими людьми на предприятии.

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

Мы часто будем приводить в качестве примера системы танец – танцы имеют процессную природу, они не такие тривиальные для мышления, как насосы или автомобили. Но танцы всё ещё много проще предприятия, поэтому думать о танцах проще, чем о предприятии. И совсем недаром одна из классических (год выпуска – 1999) книг Peter Senge по системному мышлению для предприятий называется «Танец перемен» 65 65 https://www.ozon.ru/context/detail/id/1378492/ .

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

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

Ещё раз подчеркнём: программу следует считать воплощением системы только в тот момент, когда она реально запущена на исполнение и работает, делает то, ради чего она была написана. Это довольно контринтуитивно, но исходный код программы – это не программа, а только описание программы. Поэтому программисты, которые считают, что их инженерная работа закончена в момент написания исходного кода – эти программисты глубоко неправы, это типичная ошибка. Из признания этой ошибки появилось целое движение DevOps 66 66 https://en.wikipedia.org/wiki/DevOps – программисты признали, что они должны выполнять роль не только разработчиков кода программы ( Dev elopment), но и сопровождением работы программы на рабочих серверах ( Operations).

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

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

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

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

Ещё лет двадцать назад считалось, что мир захватят сложные алгоритмы, которые будут хитро перерабатывать относительно простые данные. Оказалось, что современное программное обеспечение сдвигается в сторону работы со сложными данными, при этом алгоритмы работы с этими данными относительно просты и единообразно устроены. А поскольку сложность из алгоритмов перемещается в данные, то системным подходом начинают интересоваться не только инженеры-программисты, но и инженеры данных. Никогда не нужно забывать, что данные – это в конечном итоге описания каких-то систем, но в момент их обработки какой-то программой они сами становятся частью системы этой программы, «вещью». То есть данные для обработки их программой тоже нужно «изготовить» из первичных описаний. И когда мы интересуемся, как получить из данных полезный результат, то как и в случае программ мы должны научиться их изготавливать из исходных данных – и мы по аналогии с DevOps будем говорить о DataOps 67 67 https://en.wikipedia.org/wiki/Dataops .