Задания: системы в физическом мире из руководства R5. Системное мышление

Посты студентов Cистемное мышление
,
1

Мой рабочий проект это - Служба технической поддержки ERP систем.

Какова ваша целевая система?

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

Что изменится в физическом мире, если ваш проект закрыть прямо сейчас, чего в физическом мире не будет существовать без результатов вашего проекта?

В идеально мире программа должна работать идеально, без сбоев. Но жизнь показывает, что любой софт (компьютерный и человеческий) содержит ошибки. И это ошибки со временем проявляются и накапливаются, приводя к последствиям.
В 4D системе с большой вероятностью деятельность предприятия если не остановится, то сильно замедлится. Казначей не сможет вовремя согласовать ЗРДС, платеж поставщику не пройдет и он не поставит товар вовремя. Ошибка в спецификации повлияет на выпуск продукции. Закуперы не смогут получить корректный отчет от производства по потребностям и пойдут считать снова в свои таблички. В итоге множество человеческих и программных сбоев вернут предприятие на десять лет назад, когда все работали в эксельках. А при сегодняшних объемах производства придется раздуть штат, так как автоматизация превратится в компьютеризацию. Будет больше ошибок при ручных расчетах. Руководству сложнее будет принимать управленческие решения, так как отчетность будет готовиться вручную долго. И много еще чего неприятно ждет такое предприятие. Поэтому они готовы оплачивать нашу работу.

Что делает целевая система в физическом мире, какой процесс она в нём осуществляет, какая «непоправимая польза» наносится миру этим его изменением со стороны этой системы?

Целевая система - предприятие по производству медицинского оборудования и его деятельность, которая автоматизирована с помощью ERP системы. Это предприятие обеспечивает медицинские центры и больницы.

Чего не будет хорошего, если целевая система не будет осуществлять этого поведения

Полагаю, что медицинские учреждения столкнутся с недостатком оборудования и сбоем в его поставках.

В целом я вижу общую картину так:

  • Выбранное мной предприятие осуществляет поставки жизненно-важного оборудования для медучереждений.
  • Деятельность этого предприятия автоматизирована ERP системой, которая должна работать исправно в идеальных условиях.
  • Внутренняя команда техподдержки обеспечивает базовое функционирование системы и пользователей.
  • Наша команда техподдержки обеспечивает работу сложных учетных блоков, пользователей заказчика и внутренней команды заказчика.
3 лайка
2

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

Это надо вспомнить, что там говорилось на R1 по поводу потока ресурсов через предприятие (а эти “ресурсы”, заметим, вполне материальны). У Голдратта как раз всё началось с того, что он занимался “внедрением ERP” – но выяснил, что никто не понимает, что это и для чего нужно. Ну, он начал объяснять. В его романах ERP всегда есть, но на это мало кто внимание обращает. А надо обращать.

2 лайка
3

Анатолий Игоревич, спасибо что приземлили!)
Похоже это действительно “профессиональная деформация”, когда ты везде и по многу раз слышишь слово “предприятие” и “управление”, начинаешь верить что ты наносишь пользу именно в таких масштабах.
На самом же деле даже если посмотреть как устроена ERP, то мы видим справочники (НСИ), документы и регистры, которые содержат эти самые НСИ и их количество. Конечно, сама ERP система гораздо сложнее, но управляет она именно ресурсами, подсказывая сотрудникам где должна или где лежит какая-то заготовка, куда она дальше пойдет по техпроцессу или что вместо заготовки дырка и необходимо ее будет закупить у поставщика, иначе план производства не выполнится. Дальше там идут сложные денежные расчеты себестоимости, финансовый результат и тд, но все это обсчет именно ресурсов предприятия через другие ресурсы (стоимость, объем, вес…).
Если вернуться к моему проекту, то одна из задач техподдержки это обеспечить движение этих самых ресурсов. Упрощенно говоря, в физическом мире физическую заготовку можно руками перенести из зоны хранения на складе в зону производства. А учетная система по какой-то причине не дает это сделать, из-за ошибки программы или человеческой ошибки (например кто-то неверно спецификацию заполнил или не верно оприходовал материал). В таком случае мы как техподдержка должны предложить обходной путь, предложить пользователю решение как эту заготовку можно провести по регистрам чтобы система отражала действительность, а потом уже идти и искать в чем причина проблемы.
В итоге пользователь доволен, заготовка и в физическом мире и в учетной системе заняла свое место, а мы как техподдержка занимаемся устранением проблемы, чтобы таких ситуаций больше не возникало и ресурсы перемещались по предприятию и контролировались в системе.
Получается так, что целевая система нашей техподдержки это потоки ресурсов (материалы, товар, время людей, деньги). Буквально, техподдержка поддерживает электронные каналы по которым текут электронные ресурсы предприятия в надлежащем состоянии и помогает устранять проблемы на разных этапах.

3 лайка
4

У вас точно не ERP описан в комменте, а учёт для ERP (это, кстати, типично российская заморочка: ERP называют складской учёт, бухгалтерию и что угодно ещё. Там потока нет, только учёт). ERP – там последнее слово planning. Или вы называете, какой в вашем софте алгоритм планирования (их несколько вариантов), или это не ERP, а что угодно, что вы называете ERP. Ну, типа “дублёнка” – любая верхняя одежда, в том числе пуховка, вязаное пальто, что угодно, иногда и что-то из выделанной шкуры )))

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

Учёт и прочая “актуальность” – чтобы планирование работало. Но часто делают только учёт, а планирование как-нибудь, вручную. А модуля планирования вообще нет )))

5

В моем комментарии я привел простой пример. Да, он описывает самую простую учетную часть.

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

Упрощенно поток выглядит так:
План продаж > План производства > План закупок > Производство > Складские операции > Продажа > Рекламации

6

Не вижу потока ресурсов как объекта, который “упрощённо выглядит”, вижу последовательность каких-то объектов абсолютно разной природы:

  • план продаж – это эпистема, описание будущих продаж. Не система, не метод, не работа, а описание “продаж” (что такое “продажа” надо ещё выяснить, то ли это результаты продаж, то ли что продаём, то ли работы по продаже)
  • план производства – это эпистема, описание будущего “производства” (и тут ещё надо пообсуждать, что это за объект “производство”, тоже непонятно)
  • … и так надо доходить до конца списка, где “рекламации” – то ли эпистемы, то ли работы по рекламациями, то ли это результат “продаж” как работы и кроме “рекламаций” (что это?) там ничего нет )))

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

Конкретный софт вообще не волнует, особенно когда речь идёт о “конфигурациях”, которые сегодня пришли, а завтра ушли. А вот управляемый (хорошо или плохо) поток ресурсов – остался. И там или планирование есть, и для этого учёт. Или учёт есть, а планирование забыли – и тогда “учёт” непонятно, зачем вести.

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

Поэтому проверяйте моделирование в каждом вашем тексте. Например, у вас там “блок бюджетирования”. Что такое “блок”? Это операции? Это подразделение? Это софт (который ни разу не бюджетирует, ибо чтобы его выдача стала бюджетом, должны поработать довольно много людей, софт явно не выполняет работу бюджетирования, он только как-то содействует бюджетированию), или это просто “хранилище цифр бюджета”? Если в бюджетировании доходы и расходы – это ведь не они сами, а планы доходов и расходов, то есть описания ожиданий по доходам и расходам? Если не писать правильно, легко перепутать доходы и расходы плановые и фактические. Это всё материал R1-R4, это надо просто использовать каждый день, это не “освоил – забыл”. Это хорошо видно, когда пишется с контролем типов, а когда просто подряд идут разные объекты из одной ситуации (например, в моём перечислении все объекты из “что можно найти дома”, но абсолютно разных типов).

Так что и с целевой системой, и с моделированием вообще – ответов на вопросы пока нет, ибо нет точности рассуждения с типами, а не просто перечисления каких-то объектов.

Но ничего, потихоньку в ходе резидентуры всё это выяснится, на то и полтора месяца, чтобы всё это как-то натренировать. И материал R1-R4 надо задействовать в полной мере, это же видно, когда не используется понятие потока, не используется моделирование с контролем типов, письменная речь “бытовая”, а не точная. Это ещё не системное мышление, это ещё до него. Системное мышление начинатся с того, что там целевая система.

1 лайк
7

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

Платформа развернута, но бизнес не готов перестраивать свою работу, чтобы начать пользоваться возможностями инструмента.

8

Это вы всё разные соображения рассказываете, “инструментоцентричные”. А целевая система что? У изготовителей рубанка целевая система – оструганная доска. А ваш инструмент со всеми придающимися к нему людьми, он зачем? Поставщики ERP почему-то особенно увиливают от ответа на этот вопрос, это просто по опыту. Что в физическом мире (именно в физическом мире) не будет сделано без вашего инструмента? Вот вы в программном коде ERP поменяли запятую – и как это отразится на физическом мире? Как выяснится, что “стало лучше”?

Остальное вокруг – это ваши производственные байки, они к делу пока отношения не имеют, сначала надо разобраться, что такое целевая система. Без этого системное мышление не заведётся.

9

Анатолий Игоревич, очевидно мне нужно вернуться к более тщательному изучению и проработке руководства. Честно говоря, я только недавно познакомился с ним и это мой первый заход)
Есть над чем подумать.
Но теперь стало кое-что понятнее на приземленных примерах. Думаю, читать и прорабатывать буду уже иначе.

10

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

11

Ну не могут цифры превратиться в заказы, а потом материлизоваться на складах.

Простой вопрос: что течёт-то?

1 лайк
12

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

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

нарушения в работе ЕРП может иметь много последствий в разных временных масштабах

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

Самое больше последствие для компании - невыполнение госконтракта и передача компании под внешнее управление.

1 лайк
13

Предположу, что информация, воплощенная в электрические сигналы, 1 и 0. В Базе данных это записи, ERP система описывает как эти записи должны храниться, двигаться, менять и тд.

14

Поставщик ERP не отвечает за продукт компании, это точно. Но увиливание на вопрос “что течёт” (материальные объекты прежде всего) – детектед. ERP и приданные ему компьютеры и люди чем-то рулят (меняют состояние чего-то), что меняется в физическом мире. Без ответа на этот вопрос – не сдвинемся с места. Цифры и всё остальное – это какие-то описания. Без понимания, что там описывается и зачем описывается (для принятия каких решений и кто эти решения потом исполняет) не будет вопроса. Только материальные объекты, всё остальное идёт в зачёт как описание этих объектов. Описания без объектов – незачёт.

15

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

16

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

но все это должно двигаться по предприятию и без ЕРП. ЕРП тут - инструмент упрощения управления всеми этими потоками.

З.Ы. мне показалось что меня определили в роли поставщика ЕРП. я не поставщик, если что ))

17

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

Материалы, покупные комплектующие изделия, полуфабрикаты – вещи. Уже хорошо! Что с этим потоком делает ERP? Если в ERP поменяем какой-то алгоритм, то что произойдёт с потоком? Понятно, что подобные потоки текут и без ERP. Что с этими потоками (материальными!) делает ERP? Вот рубанок доску делает гладкой. А что с потоком делает ERP? Дальше будем выяснять, кому это надо, на что влияет, кто этим озабочен. Где-то там рядом может оказаться целевая система. По крайней мере, мы уже говорим про что-то материальное – материалы, ПКИ, полуфабрикаты, конечные изделия. И деньги (можно моделировать кучками золота, которые текут – счета просто это отражают).

18

ЕРП держит у себя состав изделия в классах.
На основании этой информации и других вспомогательных справочников ЕРП + план производства ЕРП вычисляет дифицит - который конвертируется в потребность которую должно обеспечить МТО (закупки).

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

целевые системы выпускаются сериями. каждый экземпляр имеет свой номер и требует конкретные номера агрегатов в своем составе на этапе сдачи-приемки. ЕРП эту целостность конфигурации должна обеспечить. Она в идеале не должна пропустить агрегат не с тем номером на конкретный экземпляр целевой системы.

Это выражается в том, что в конкретный день конкретный кладовщик не должен иметь возможности выдать со склада в производство агрегат не с тем номером (когда имеется в виду конкретный агрегат с заводским номером).

19

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

Не написано, что делает с потоком и что поток, ибо там только “держит состав”, “вычисляет дефицит” (и там ещё есть потребность, в которую сам себя конвертирует дефицит).

Дальше там ERP “контролирует индивиды на попадание в поток”, ничего опять про поток, только про попадание в поток.

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

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

Я очень просто читаю тексты: в каждом предложении есть подлежащие и сказуемые. Я внимательно читаю и пытаю определить, что с какими объектами там делается. Вот буквально читаю, по одному слову – и смотрю типы слов и какие с ними операции.

Почему-то люди, когда пишут программы, они заботятся, чтобы там всё со всем связано в тексте было, описывают алгоритм. А тут не описан алгоритм, тут разрознённые какие-то операции с разными объектами.

Нужна точная речь, моделирование на уровне псевдокода в тексте. Ну, и чтобы там была целевая система предприятия, был поток как целевой для ERP. И понятно было, как они связаны. И всё это объясняемое за пару минут (“лифтовый тест” – ибо с начальником едем в лифте и у нас всего пара минут, чтобы всё-всё объяснить и потребовать на эту ERP денег так, чтобы он не мог отказать).

2 лайка
20

Попробую я ответить.

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

Пользователь ERP является как потребителем, там и создателем - он наполняет систему данными, отражает поступления, перемещения, отгрузку или изменение свойств объектов.

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

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