Является ли Odoo АСУ? Расшифровка мастер-класса
Спикер 2 (МК):
Пошло. Так, давайте, значит, я сейчас включу демонстрацию экрана. И самое интересное, это у нас вот это вот.
Спикер 1:
Вот это вот. Я тебе прислал старый слайд, который я сделал, что он листается по порядку.
Спикер 2:
Так, я давай его пролистаю до конца, потому что мне очень хочется его обсудить. Но я, на самом деле, часть из него понимаю, а часть из него, конечно, не понимаю. Сегодня мы собрались обсудить вот эту логическую структуру ОСУ, и как в ОДУ, какие куски и какие части удовлетворяют этой идеальной структуре ОСУ. Поэтому, может быть, скажем так, ты, Игорь, какие-то наводняющие вопросы мне будешь задавать?
Например в формате близ вот как вот мы с тобой любим хорошо получается смотри идея какая что.
Спикер 1:
Была пирамида и с нее вышли уровни теперь пирамида не работает по двум причинам во первых потому что серийных предприятий больше нет где вот это концепция месс родилась, но что сбыт продал на три года вперед, а потом мы пилимся тихонечко сбыт планирует нам поставки на следующий год и мы вынуждены вот этот вот DG MRP устраивать принудительно, ну то есть устраивать принудительно, ну балансировать между сбытом, заказами, разузловкой, производством и поставками.
В том числе у нас могут быть дефицитные компоненты, то есть у нас сейчас спрос у большинства вырос, да, то есть у всех спрос это, а персонала нет ни у кого и с поставками проблемы чуть больше, чем у всех.
Ну и плюс вопрос нужен конфигуратор очень сильно на большинстве продуктов даже потому что менеджеров не хватает и если мы плохо договорились с заказчиком то у нас будет проблема и вот что выходит что сейчас народ пизжит мессы потеряв логическую структуру может быть они делают круто системно они крутые программисты у них там в микросервис и рестапе, но с точки зрения логики это похоже на кардак и культ. Вплоть до того, что один проект они пилят, прямо пилят сразу, пытаются повторить ОВВА.
И получается, они повторяют внешние атрибуты, а внутри у них получается куча кострелей. Хотя, я думаю, что структура логическая может быть достаточно стройной. Что вот мы собрали какие-то и мы их должны в сущности переобразовать. Потом мы с этими сущностями, у нас есть какие-то операции, и у нас где-то в документации написано, что, ребята, вот это вот у нас, ну, условно, там, заказ, или это у нас сигнал, или это у нас состояние, или это у нас то.
Он может быть преобразован туда-то и туда-то, объединен с тем-то и с тем-то, из него может быть порождено то-то и то-то. Ну, то есть нормальные, то есть операнды и операции. Народ уже слова такие забыл. Вот в чем проблема.
И на вот отсюда вот попытка разобраться с логической структурой потому что люди пытаются добавить функционал потребования заказчика заказчик не может посмотреть на это системой разработчик получается куча костылей которая рушится или начинает жить своей жизнью какой-то момент.
Спикер 2:
Да, вот такое же наблюдение, что я сейчас вижу на практических проектах внедрения. Во-первых, люди, скажем так, те, которые посовременнее, которые обладают субъектным мышлением, они перешли на новый уровень абстракции. То есть они уже не мыслят какими-то заказами, продуктами и так далее.
Они мыслят, скажем так, абстракциями более высокого уровня, уже мыслят потоками. Соответственно, это что касаемо заказчиков. Что касаемо информационных систем, которыми пользуются. Здесь вообще страшная история. Во-первых, нету никаких больше коробочных решений. Их просто попросту нет.
Если раньше можно было создать какое-то усредненное коробочное решение с каким-то уровнем логической организации, что там все вроде более-менее как бы есть, и это подходило большому количеству организаций, то сейчас я наблюдаю, что такого больше нет. И что же делать, да? Вопрос. Делать какое-то новое, крутое, супер-мега-коробочное решение?
Я думаю, вряд ли. Мы пошли по пути того, что мы делаем индивидуальные сборки, скажем так, индивидуальные сборки. У нас куча разных компонентов, и мы под клиентов делаем индивидуальные сборки. Это начинает соответствовать их уровню мышления, ну и, соответственно, получается нормальная, хорошая, высокая скорость внедрения. Что же касается вот этой пирамиды, сама система ОДУ, с которой мы занимаемся, она построена достаточно толково с логической точки зрения.
Я сейчас переключу на другую вкладку. Это у нас с вами ОДУ. Самое интересное, что, во-первых, введено такое так называемое понятие «модель». Модель — это по факту отражение в цифровом мире нашей обыкновенной сущности из нашей жизни.
Причем модели могут быть, так сказать, немножечко иерархические. Например, у нас есть движение по складу, скажем, такая операция. Но у нас же еще и складское требование, стокпикинг, она может порождать складскую операцию. У нас есть заказ-продаж, но в нем есть строки, а в строках есть там какие-то дополнительные атрибуты.
И все это в каждом местечке своя собственная модель живет. Налог — тоже самая модель. Продукт — модель. Все у нас модели. Таким образом мы можем построить такое вполне себе интересное дерево любой информационной структуры которые нам только потребуется и мы можем перемещаясь по уровням этого дерева спускаться на самый глубокий уровень абстракции до самой самой нижней вплоть там до каких-то полей да то
есть это атрибуты их значения и повышая например до уровня консолидации финансовой отчетности или там складской отчетности нашего предприятия и очень забавно то что на самый нижний уровень теперь уже практически не приходится забираться значит смотрите какая интересная вещь заказ обыкновенно теперь поступает автоматически то есть сайта после работы конфигуратора или через ЭДО или через EDI, то есть люди перестали работать с полями, то есть они начинают работать непосредственно с заказов.
Если раньше люди работали с каждым полем в заказе, вот давайте посмотрим модуль продажи, у нас есть заказ, в заказе у нас есть строки, и вот люди раньше во всех старых системах оперировали с этим, теперь это уже уходит на второй план.
То есть мы уже повышаем уровень абстракции дальше мы говорим мы теперь мыслим потоками мы когда нажимаем подтвердить заказ у нас автоматически возникает то самое складское требование да то есть наш пикинг опять-таки мы за строками уже здесь не следим за товарами не следим за всем уже начинается видеть систему то есть это такой же такой путь развития автопилота то есть коробка автомат в машине, это элемент автопилота, уже элементы автопилота, они в нашей жизни очень давно стали встречаться.
Какие-то рутинные вещи давным-давно автоматизировали в БТУ, ну и тем более как бы на производствах, ну и в том числе в системах управления производственными предприятиями. Дальше, если мы, например, захотим сделать запуск заказа на производство, нам тоже не потребуется ничего такого делать, да?
Мы нажимаем кнопочку одну подтвердить у нас раскручивается вся вся цепочка раскручивается спецификация мы плотную приблизились к тому чтобы контролировать машину вот не контролировать сущности, а контролировать машину которые за нас управляет нашими потоками это важная история да потому что если мы
сейчас вернемся к нашей к нашей базовой модели то мы смотрите мы сырые данные мы теперь за ними вообще не следим вообще не следим только глазками и то только в проблемных местах значит дальше транспорт шина я сейчас рассказал история что мы можем запустить например отгрузку со склада просто одной кнопочкой
подтвердив заказ все все документы электронные которые необходимы для этого они сформируются сами мы быть может их никто никогда в жизни даже из человека не увидит и не посмотрят что там сформировался какой-то документ.
Спикер 1:
Вопрос подожди давай мы тебя на этом месте остановим запомни где продолжить и смотри первое что мы должны отличать когда у нас идут составные модели то Допустим, заказ у нас состоит из понятия договор, которому он подчинен, то есть это вышестоящий к нему объект.
Он состоит из субъекта, то есть кто у нас заказывает, и он состоит из набора строк, то есть какого-то циклического или последовательности. И теперь мы понимаем, что у нас модели могут быть составные, когда модель более высокого состоит из маленьких, что мы имеем подчиненность моделей, что мы имеем каскадирование моделей совершенно разное, когда одно порождает другое, что мы имеем ветвление, что из одной модели мы можем пойти по двумя путями, разными, скажем, маршрутами.
И второй момент, что если мы вернемся на схему, то мы понимаем, что мы не просто так сырые данные, потому что у нас возникает на каком-то моменте, что отдайте эти данные в БИАйку.
Ну, допустим, мы прикрутили какой-то Apache суперсет, и он у нас выкачивает и сырые данные, и этот, потому что тут были еще вот эти маленькие, а они важные. Почему? Потому что у нас получается не пирамида, а такой двугорбый верблюд, то есть из него несколько начала вершин расти.
Потому что, допустим, если ты прикрутишь какую-то экспертную систему, она может у тебя оперировать и сырыми данными, и уже какими-то агрегированными данными, то есть поедать твои сущности, то есть определять, оперировать свойствами твоих уже сущностей более высокого порядка. И она может даже потребовать от тебя тех данных, которых нет в ОДУ. То есть, например, каких-то временных рядов или чего-то другого, чего вот ей надо, оно в этих данных есть, но ОДУ его для себя, для управления производством не выделяет.
У тебя появилась вот такая вторая вершина, которая растет от сырых данных. Еще она по пути с каждого этажа может подтягивать, как уже брать готовую аналитику из ОДУ, как анализировать операции, допустим, экспертная система может и первичные данные поедать, и данные об операциях, и вот это вот надо понимать, что есть несколько моделей,
то есть составная, каскадирование и наследование как минимум, и маршрутизация, то есть это надо как свойства объекта описывать отдельно, что у тебя вот условная накладная состоит из того-то, того-то, того-то, что она может быть порождена тем-то, тем-то, тем-то, то есть какими-то источниками или какими-то событиями, и что она может у тебя превратиться в то-то, то-то, то-то, или она автоматом порождает то-то, то-то, то-то.
И вот это совершенно разные, по сути, операции. И когда пытаются объединить в одну, то есть получается полная каша. А если понимать, что сейчас происходит, то и в коде разбираться проще, ну, собственно, как это все построено уже в системе, и развивать эту систему дальше проще, когда ты потом хочешь какую-то функцию прикрутить или какой-то маршрут, или что-то переделать. Вот это в два момента.
То есть, первое, это что у моделей есть разные отношения, разные типы отношений. Ну, как минимум, вот возьмем там, то есть, составная модель, каскадируемая модель, наследуемая модель и порожденная модель. И вот что у тебя в любой момент, у тебя API нет как такового, что у тебя допустим запрос может быть и к сырым данным, и запрос может быть к транспорту, где у тебя какие-то агрегированные данные, ну то есть опереживающие состояниями там, сигналами и так дальше.
И запросить какие-то более высокие сущности, то есть допустим мы берем и сделали себе там какую-то систему, неважно на чем, там на GIF-урах или на нейронках, который анализирует накладные, то есть ищет какие-то непонятные для нас или важные для нас параметры в накладных.
И тогда мы должны подать набор накладных и набор свойств, то есть вот эту всю историю, то есть историю операции в данном случае и системы, для того, чтобы она нашла какие-то тренды. И там эта история уже разделяется, то есть ищем мы исторические тренды или пытаемся ли мы прогнозировать, или пытаемся мы найти неочевидную связь факторов, или наоборот, мы ищем какую-то конкретную связь факторов, то есть, допустим, какие-то накладные, которые соответствуют тем-то или тем-то параметрам.
Но это уже боковая ветвь дискуссии, как и с экспертными системами. Сейчас мы говорим, что у нас нет вот этой однозначной вертикали, потому что от нее в любой момент может отколоться ветка, которая будет оперировать этими сущностями. И что у нас есть набор, ну то есть у сущности есть ее родительские сущности, дочерние сущности, смежные сущности и наследуемые сущности.
Понимаешь, о чем я говорю?
Спикер 2:
Я-то понимаю, да, и коллеги должны тоже понимать. Я еще даже поясню по поводу этих сущностей. Есть у нас вот эти смежные сущности, которые Mixol дают нам возможность миксования. То есть, представьте себе, что у нас есть какая-нибудь модель, которая, будучи добавленной к любой другой модели, наделяет ее соответствующими возможностями. Условно. Есть у тебя модель, которая умеет принимать данные, например, с датчиков.
И ты говоришь, а я ее могу просто взять и одной строчкой кода присоединить, например, к заказу на производство. У меня повалятся туда данные машинные. Вот. Ну окей, не нравится мне заказанное производство. Я там к наряду, к сменносуточному заданию. Хоп туда. Без переписок. То есть я оперирую уже модели. Все прекрасно помнят о том, что у нас с вами есть такая штука, как чаттер.
Вот это вот, да? Которая ведет историю, отправляет сообщения там и, в общем, ведет протокол по каждому документу. Так вот вот это вот тоже самый пример миксованной смежной модели которые мы просто добавили заказу продаж и все у нас все понеслось значит давайте пойдем дальше да я хотел сейчас вернуться посмотри вопросы в чате может если они
Спикер 1:
относятся к этому, то сразу на них ответить, то есть ну что-то.
Спикер 2:
Мои вопросы в чате сейчас так показывают, что я его не вижу. Так, я сейчас открываю. Добрый вечер. Как приняли заказ без подтверждения даты? Ну, я сейчас показывал заказ уже подтвержденный, да? Давайте я отвечу на вопрос.
Дата заказа у нас здесь у нас система сама рассчитывает когда дата будет дата отгрузки планируется вот когда мы соглашаемся с этой датой мы и подтверждаем на этот заказ если у нас устраивает нашего клиента всех остальных вот, а если мы хотим ее сдвинуть вправо левее двигать нельзя вот если хотим вправо мы эту дату можем просто в явном виде здесь написать взять и написать какую-нибудь дату, которая нас нас устраивает, поэтому с датой вопрос такой давайте по поводу все-таки
по поводу нашей структуры да значит мы остановились на том что у нас мы перешли в сущности да это вот наши самые модели да сущности они являются операндом ведь как вот мы сейчас вот сыгрим рассказываю как мы их перебираем логическим образом компонуем перекидываем друг на
другу ставим смешиваем вот они операнды это то над чем производим операции какие же функции давайте смотреть, а вот функции мы с вами все прекрасно знаем функция это кнопочки действия которые мы можем сделать над этим операндов и у нас есть специальный даже вот так здесь в воду есть специальная такая кнопочка действия прямо называется вот это функции они вынесены прямо даже отдельно я могу печатать я могу дублировать
могу удалить могу там сделать дополнительные разные контекстные действия которые я могу сделать.
Спикер 1:
Над этим над этой сущностью над этим, но еще есть действия которые делают алгоритмы то есть когда есть какие-то прописанные маршруты и какие-то над ними действия автоматические, то есть когда событие автоматом вызывает то-то, то-то, то-то. И вот это, кстати, интересная история, надо ли это отражается, или это всегда в чатере, надо ли это отражать в чатере. И, кстати, сразу такая идея, что, возможно, надо анализировать чатер на предмет, ну, чем совершеннее процесс, тем короче чатер.
Но в идеале в чатере ничего ручками не пишется, потому что тебе понятно, что делать, и ты делаешь действия, либо они делаются автоматически. Если тебе приходится хозяину сущности что-то писать, то значит это уже какое-то неученое ветвление в процессе, еще что-то, что требует от тебя какого-то ручного вмешательства.
Понимаешь, вот это вот возможный признак.
Спикер 2:
Да, это плохой признак. Вот в чатере вот давай сейчас посмотрим какие-нибудь чатеры посмотрите вот этот вот чатер записан полностью машины потому что я менял значение полей она за мной все это дело записывала и она сюда бабахнул просрочку то есть эта машина мне сказала что у тебя там вообще как бы все не
все и пошло не так как надо сама зарядила сюда мне активити вот такую штучку да чтобы я посмотрел чтобы она она мне зажгла эту активити здесь в красных этих штуках в часиках и в чатере то есть у меня здесь видно что там один пикинг у меня что-то с ним не то да одна запись журнала с ней там какая-то проблема заказ на продажу в общем все мне выводит то есть я на самом
мы приближаемся к чему дальше идем смотреть мы добрались до функции то есть функции у нас есть мы их специальным образом даже в системе имеем в виде в явном виде для ручного исполнения и конечно огромное количество функций для автоматического исполнения и каждая функция которая у нас выполняется по хорошему оставляет след в виде протокола что она
сделала когда и почему вот будучи так сказать поклонником товарища масаловича я задавался вопросом никто не понимает почему искусственный интеллект так называемый да принимает то или иное решение и они на средних уровнях да вот это не ровно внутри на глубинных уровнях не могут понять то есть сначала с конца все вроде как бы ясно, а в серединке не ясно и проблема глубокая люди умные понимают что для
разбора полетов всегда нужен протокол так вот мы работаем с детерминированными алгоритмами мы можем вести четкий понятный ясный протокол поэтому даже когда мы делаем доработки мы всегда реализует ту или иную функцию всегда пишем протокол почему было принято такое решение и каковы результаты обработки этой функции. Дальше поднимемся. Модули, да?
Мы с вами поняли, что из моделей мы собрали какую-то логическую структуру, придумали функции, которые можно над ними исполнять, функции печати, дублирования и так далее, и огромного количества всяких сложных функций. А теперь мы поняли, что на самом деле есть абстракции более высокого уровня, который называется модуль.
Модуль это функциональная группа моделей, действий и функций, которыми можно выделить в отдельный даже визуальный интерфейс. Например, все привыкли, что у нас закупки и это отдельный модуль. Выглядит все у нас одинаково абсолютно. Вот, например, дела, тудушки такие у нас, канбанчик.
Тут у нас с вами модуль учет, например. Вот они логическим образом сгруппированы, но модули между собой обязаны общаться, потому что у нас же все-таки общая шина, мы через нее все прогоняем. У нас общие базовые данные. То есть если мы возьмем и разложим полностью всю систему на какие-то самые низкоуровневые компоненты, то мы увидим, что все на самом деле строится вокруг очень малого количества базисных, скажем, операций.
Это проводка движения денежных средств, так называемый аккаунт мув, движение денег. И вторая это сток мув, это движение по складу. Вот учет, вот он, на 2 этих компонента он и навешивается.
Это вот базисный учет. Все остальное это дополнительные, сопровождающие какие-то документы, модели, вот эти вот конструкты там и так далее. На самом деле всех интересует два контура, да, складской контур и финансовый. Финансовый, внутри финансового контура тоже денежный и этот сам учетный. Вот и все. А все остальное как бы это надстройка. Мы же, например, когда говорим, как работает компьютер, вот у нас питончик, мы там три строчки написали, у нас запустилась большая языковая модель и появился в консольке чат.
Мы три строчки написали, но все же это закручено в библиотеке. В библиотеке написано или на питоне, или на сях, да? Вот все это дело в итоге сводится к чему машинному кода все равно машины исполняется и также у нас здесь у нас все равно исполняется вот эти базисные базисные проводки делаются их в огромном количестве формирует система и на них
все строится и на них все опирается поэтому не нужно забывать, но при при проектировании, при обучении людей, при разработке каких-то новых модулей, вот на те базовые низкоуровневые объекты опираться вообще не стоит. Мы работаем на одном из очень больших проектов, как там, вспомогательная команда, и там руководители проекта допустили ошибку.
Они, разрабатывая систему на ОДУ, они проектируют справочники они проектируют вместо модели проектируют сущности базе данных то есть они сначала имеют логический конструкт в голове потом раскладывают это вот дело туда проворачивает обратно вот этот так сказать логический фарш ассемблер, а потом из него пытаются программист построить модели и они
тратят огромное количество времени денег на вот эти никчемные операции получается на самом деле даже как испорченный телефон поэтому это очень большая ошибка очень популярна и очень популярная скажем так поехали дальше смотреть мы добрались с вами вот досюда до модулей конструктов, а теперь хотею хочу показать по поводу управления в самом начале нашего
разговора я рассказал сказал что у нас с вами до вот этих низкоуровневых данных до строк заказов там до количества может быть даже люди как бы не добираются вопрос, а как же собственно происходит управление вот какая история перед нами такой специализированный управляющий дашборд раньше его называли арм вот это тоже
слово очень нравится, но его как бы люди не очень понимают значит этот арм позволяет нам в одном месте сразу найти всевозможные отклонения по этому модулю значит вот например вот счет фактуры для клиента мне отклонение следующие значит не оплаченных 19 просроченных 19 на утверждение вот это вот один значит по банку не
разложен 205 элементов то есть она прям пишет что нужно сделать баланс это тебе для справки 3600 да проверить ну переводы мы кстати здесь составляем за скобками потому что над переводами над русскими мы работаем кто-то угандошил переводы которые переезжали с 15 на 16 17 просто крах вот и сейчас русскими переводами занимается только наш консорциум мы уже продвинулись серьезно я думаю что к новому году будут отличные
переводы почти всех модулей значит дальше по отклонениям смотрим если мы вот эти верхний уровень вы отклонения здесь анализируем да то, а все кликабельным может провалиться то есть мы меняем уровень абстракции тут же и у нас совершенно арм преображается у нас более детальной информации до нас доносится и она уже, а светофорина вот как игорь любит светофор я с тех пор полюбил тоже
очень сильно значит все сбойные у нас красная все требующие внимание у нас желтые какие-то куски которые показывают что по учету у нас проведено, а платеж платеж здесь вообще не оплачен здесь частично оплачен там так далее то есть на самом деле то что мы сейчас видим это как раз arm arm alarm arm alarm да то есть нужно чтобы вот эту штуку обработал человек если все хорошо и
все идет своим чередом выписка грузится выписка разносится товар отправляется то arm alarm у нас нулевой аналогичная история с банком мы здесь заходим и смотрим что жуткое количество платежей просто не разнесено просто не разнесено мы выпуск увидим разнести никто не захотел вот ну здесь вот в принципе все абсолютно аналогично, но мы же можем написать некий скрипт или
Спикер 1:
какую-то функцию прикрутить что условно каждый понедельник просроченным счетам напоминать ватсап там руководителю и менеджеру в электронку что как там это больше верни деньги да на самом деле.
Спикер 2:
Промышлые деньги уже давно давно все сделано это вот в англоязычной истории называется follow up вот или follow up да значит как раз фигня которая по зараннему заданному заданным цепочке эскалации проводят вот эти неоплаченные вещи, то есть сначала тебе письмо, потом значит второй раз если там в течение там еще сколько-то дней не оплатил, тогда уже на вид руководителю, ну и так далее, то есть это все можно как бы здесь собирать, то есть управление подклонением уже начато, скажем так, ну собственно в промышленную эксплуатацию, да, конечно мы все всегда пишут себе допилы всякие разные,
сводки дашборды бот это все сделано для того чтобы наладить себе управление подклонения я вот хотел показать дашборд это конструктор дашборд вот вот вы видите что он даже по дизайну оттуда отличается вот и видно что здесь у нас есть система редактирования этих дашбордов и эти дашборды
как раз помогают нам собрать качественные показатели для отправки ну для демонстрации руководителя если мы говорим что мы внедрение делом качественно соответственно мы должны первым делом снабдить правдивые информации наших любимых lpr иначе грош цена нашему внедрению дальше пойдем посмотрим что у нас там по нашей многоуровневой системе
анализ прогноз да и вот мы добираемся до самой верхней этой истории то есть мы уже так потихонечку справились с отклонениями смотрели что мы можем все какие-то компоненты важнейшие для последующего элемента анализа да вывести на дашборде есть вот внештатный модуль такой достаточно мощный ну и конечно есть штатный модуль с дашбордами вот такой пример вот здесь в принципе все что есть все что нужно все
есть я вот например зайду финансы и мне тут кое-какие показатели посчитали слайд видим мы видим слайд, а слайд извините пожалуйста да значит я вернусь на секунду назад это штатный дашборд тот красивый вам показывал не штатно, а этот штатный у штатного дашбу штатных дашбордов у них такой вот внешний вид скажем так себе, но это конструктор и с ним можно работать тут и работают фильтры тут работают формулы тут можно все собирать и подписывать дописывать себе вот эти вот Dashboard.
Есть даже светофорный бенчмарк. Маржа, валовая прибыль, операционная маржа 83 процента. Вот эти показометры, они, конечно, очень красиво радуют любого LPR. И этим надо пользоваться.
Логистика, например. Запасы на руках. Тоже можно смотреть такую историю. Таким образом для аналитики вроде у нас инструментарий имеется еще кстати скажу что у нас например есть в любой модели который более-менее такая развитая например там invoice у нас есть анализ документов продажи у нас есть штатная история с аналитикой То есть мы имеем представление в виде графика и представление сводной таблицы.
Сейчас я переключусь. Переключение сводной таблицы. Вот это такая штука. Сводная таблица есть у всех существенных моделей. То есть заказ-продаж, заказ на производство. Все вот это у нас есть. Я могу настраивать прям как хочу.
Я скажу так давай мне скажу значит категории продукта здесь не заполнено например по продуктам компании дата уже что-нибудь еще там пользовательская группа какая-нибудь продукт здесь у нас будет продукт, а здесь у нас будет даты значит дата по квартально показывают сумма все кликабельно если меня интересует откуда взялась сумма например
там 17 550 я нажимаю мне документ продажи пожалуйста здесь прям сразу демонстрируется то есть это элементы важнейший элемент нулевого уровня бирайка элемент анализа даже борды плюс бирайка вот это вот стройная на самом деле даже среднему бизнесу это вот обычно хватает вот базы данных работы достаточно шустро поэтому в принципе с ней проблем нет, а и у нас с вами имеется
уже прогностическая история я вот ее тоже начну показывать вот представьте у нас с вами тестовый клиент он покупает нас вот какой-то блок вот это вот эти красные горбики это есть история про прогноз я давайте покажу прогноз есть прогностическая история про каждый товар системы знает когда он должен быть
отгружен в плане да когда у нас там по будущую отгрузки сколько заказано сколько производстве и она умеет ждать она умеет ждать умеет показывать какому числу у нас будет какой прогнозирование прогнозируемый уровень складских запасов ну здесь вот минус 5 минус 5 до бесконечности да потому что никаких документов там скажем так не планируется вот эта штука она встроена везде
то есть если мы пойдем например в модуль склад модуль склад кстати вот по поводу функции да у нас есть функция прогноза она дает нам визуальную картинку вот, а есть функция прогноза который сейчас я ищу слово склад вот у нас есть складской отчет отчет запаса вот у меня есть соответственно каждый товар с остатком и по нему здесь можно принимать решение сейчас давайте
посмотрим здесь продукт список на шаблон прогноз вот прогноз вот здесь видите минус 292 то есть прогноз он умеет считаться там по специально вызванному компоненту, а также присутствует пожалуйста во вьюшках, которые доступны пользователю. То есть человек, который, например, формирует тот же самый заказ-продаж, он может в любой момент посмотреть, а когда будет. Если нет, то когда будет.
Система уже сразу подсказывает, я всех учу. Если горбик синий, все, можно грузить. Вот если городок красный, то соответственно она система не знает где продукт и она говорит, что я даже не могу на твоих складах это найти. Тебе придется поработать руками. То есть как вот у нас двойщику, да? Два балла красным поставили, все там перечеркали. Значит придется делать работу над ошибкой.
Чтобы нам не приходилось делать работу над ошибкой, мы должны так настроить систему, чтобы никакой красноты у нас никогда не было. У нас, например, опираясь на этот прогноз, та же самая готовая продукция, мы можем сделать правила, которые… Так, это не те правила, здесь перевод, сейчас я найду. Правила дозаказывания.
Это система автоматического принятия решений по пополнению. То есть она опирается на прогноз. Максимальное количество, минимальный маршрут можно выбрать. Я скажу допустим, что я должен поставить производство, когда у меня минимальное 200, а максимальный 540. И к заказу она тут раз и запустится. Мало того, у меня здесь есть кнопочка разовый заказ.
То есть я из прогностической, аналитической истории могу переходить уже к системе принятия решений, которой на нашей схеме нет. Был сформирован следующий запас на пополнение запасов. Заказ на производство был сделан. Вот, вот я его открою в новом вкладке. Вот, пожалуйста, заказ на производство сделался только что. Вот, у меня сразу потребность в компонентах, у меня сразу производственные задания сформировались, он ожидает компонентов.
И все это сразу повлияло на дефициты на тот самый прогноз у меня вот например компонент 1 компонент 2 он вообще есть он зеленым горит, а если бы его не было я бы мог оперативным образом его дозаказать вот таким образом мы добрались до самой вершины да то есть у нас получается такая достаточно интересная система которая в принципе удовлетворяет вот это вот структуре единственно к ней в штатном варианте нет, не прикручена никакая штука с искусственным интеллектом.
Я думаю, что это вопрос времени, потому что письма с искусственным интеллектом она писать уже научилась, а вот решение принимать пока нет. Искусственный интеллект бывает разным, бывает на нейронах, бывает на дифурах, бывает соответственно на интегралах, которые я вот исповедую, на интегральной напряженности работаю, мы делаем автоматические планировщики.
Планировщик это система принятия решения. Планировщик позволяет оптимальным образом построить сменно-суточные задания или там сделать распределение задач на проектах. Об этом я кстати как-то рассказывал. Я думаю, что после того как что-нибудь приличное сделаем, я обязательно расскажу более подробно. Ну вот в принципе, наверное, все, что я сегодня хотел рассказать.
Если есть ко мне вопросы, давайте их обсудим.
Спикер 1:
Ну, смотри, мы не обсудили ту часть, которая мне вообще непонятно как сделана, хотя время вышло. Смотри, первое, сигналы, маршруты и документы ты оставил. Самая простая история документы, это что есть документ? Это некий срез, отражающий какое-то событие. Ну, условно, договор, что мы в такой-то момент договорились о том, что в какой-то момент произойдет что-то.
И то есть приняли на себя обязательства. Сложнее история с маршрутами. И вот, допустим, конфигуратор документов. Ведь ты же специально его пилил. Вот эта история, понимаешь, что с любого среза вообще было бы правильно, если бы у нас был конфигуратор, который нам документ точно так же составляет. Документ — это некий срез состояния системы или фиксирование чего-то.
Ну, что вот вопрос — документ, который подтверждает, то есть, условно, технолог разработал такую-то техкарту. То есть, что произошло, тоже как набор сущностей, но отфиксированный на какой-то момент. Второй вопрос, что описать сигналы, то есть, что является сигналом. Почему? Потому что у нас, может быть, некий бит от внешней системы является очень важным сигналом, что у нас там «Газпром» украли, а может быть, этот сигнал — просто это точка на временном ряду, что в данный момент она не является сигналом.
Ну, вот, какое-то событие, да, то есть, ну, допустим, аварийный останов или аварийный сигнал, а может быть, что это просто температура в печке в данный момент. Ну, идет термограмма, что это, ну, такой же бит, он ничего не значит. То есть технически это одинаковые сущности, а логически совершенно разные.
Что мы должны иметь возможность описать сигнал как некое событие, которое вызывает такие-то действия, ну условно, разыскать главного механика и сообщить ему то-то, ну неважно каким способом, там через чат, через это, через там громкоговоритель, и еще вопрос он может предполагать такие-то реакции, и причем это может происходить по каким-то условиям, вот что есть сигнал, да?
Спикер 2:
Ну классическая то есть по этому самому по келдышу то есть у нас соответствующая шина.
Спикер 1:
Сигналов шина шина сообщений раньше у тебя звонил телефон при кошке ты бежал братьев не знаю теперь ты у тебя сигнал предполагающий тебе какую-то одну оболочку упаковку и ты видишь кто звонит может быть разная реакция плюс ты можешь прикрутить разные мелодии, то есть не только по визуальному каналу смотришь на экране, ну, видишь там меня или Коробкова, а ты можешь привязать разный звук, вплоть до того,
что ты можешь привязать сигналы условно, ну, то есть включить свет или там это, да, то есть какие-то другие формы информирования, то есть и другой канал, и другой маршрут. И вопрос, что сигнал ожидает какой-то формы реакции. То есть сняли трубку, одна реакция, 10 гудков не сняли трубку, то есть переключаемся на автоответчик. Вот вопрос, можем ли мы в ОДУ описывать эти сигналы.
Или мы должны это все держать в голове, или у нас есть какой-то вопрос описания документов, описания маршрута, описания сигнала. Маршрут — это вообще история, потому что формально все Канбан — это маршрут. Чеклист — это маршрут, ну очень такой скромненький. Техкарты — это маршрут. СОП — это маршрут. Технологии — это маршрут. Скрипт для продавана — это маршрут. Карта пути клиента — это маршрут.
Карта пути заказа — это маршрут. Процесс — это маршрут. Понимаешь, у которого, конечно, набор действий, набор контрольных операций, то есть вещи и так дальше. Ну, так как говорится, все в жизни либо проект, либо процесс. А процесс — это воспроизводимый проект. Да, воистину.
Спикер 2:
По поводу маршрутов, я вот уперся в одну историю. В самом ОДУ большинство маршрутов над типовыми объектами, операндами, у нас прибит гвоздями, и мне это не нравится. Вот значит если есть у нас карта маршрут клиента вот он от серыма идет через в этот самый в продаже потом на отгрузку вот он есть как есть все и ты хоть что делай без доработок ты маршрут не
изменишь мне это не нравится я коллегам уже показывал на нашем консульции мы сделали универсальные маршруты через гипер граф, но пока что технологии экспериментально и на живых людях мы пока что не применяем в чем суть мы имеем граф состояний ребра это у нас действие и мы любые документы любые модели прогоняем через вот этот граф они там взаимно
поглощаются взаимно там рождаются один на основании другого то есть это вот эти вот такие информационные маршруты собираются проще всего это понять по в работе все знают как работает техподдержка заявки и тсм да то есть пришла заявка и вот понеслась там купите картридж это не купается дядя петя не согласовывают потом согласовали потом нужен директор потом нет финансирования и в итоге короче мари ванна всю неделю не печатает ходит
печатать из бухгалтерии на производство уже сайт как там или ребята работают вот это касаемо маршрут их просто попусту нормальных вот в этой информационной системе не прибитых гвоздями нету я сейчас провожу работу над этим вопрос и что мы.
Спикер 1:
Будем делать 2 еврейский вопрос, но смотри про что вот допустим low coding только на этом и выводит и в эту сторону идут многие системы что все в жизни является процессом и ты описываешь процесс и потом его уже в зависимости от бантиков ты показываешь механику, говоришь, ну, это аварийный ремонт у тебя. Он говорит, о, классно, у меня есть аварийный ремонт.
А ты ему покажешь, это плановый ремонт. Потом ты описываешь другой маршрут. И возможно, что ты просто маскируешь в библиотеке. Ну, то есть ты технологу не показываешь операции, которые только для механиков. Механику не показываешь операции технологические, потому что он их не использует в маршруту. Ну, условно там, что у тебя вот там сидят люди, И один использует только гласные буквы, другой только согласные, а третий шипящий, не выговаривает.
Так вот, вот эта история про маршруты, то есть, ну, как сделать так, чтобы, возможно, должен быть внешний какой-то конфигуратор маршрутов, возможно, он должен быть локальный какой-то, или вообще технология самоустройства системы позволяет вот это настроить хотя бы внешний маршрутизатор?
Потому что маршрут есть, понятно, есть точка, ну то есть кто может инициировать маршрут, потом есть префиксы, что должно быть сделано, потом есть требования к стартовому состоянию, то есть начинаем, не начинаем, потом есть взаимосвязь, то, что вводу реализовано, что у тебя, вот у Волченко это реализовал, что мы не начинаем то-то, пока не начато то-то или не начинаем то-то, пока то-то не завершится, не можем начать, Или наоборот, не можем завершить раньше, чем не завершился какой-то другой процесс, да? Вот это, ну, префиксы. И вот потом у тебя идет набор операций, и у тебя там возможность ветвления, циклы и условия.
Ну, и…
Спикер 2:
Давай я сейчас покажу эту историю. Это вполне себе живая штука. Смотрите, у нас есть так называемый процессор SLA. И как раз на на этом самом гиперографе что здесь есть узлы процессора это вот состояние соответственно это состояние мы зайдем в какое-нибудь состояние вот и посмотрим что в нем есть
здесь выглядит все на самом деле очень страшно, но смысл какой уже начинает появляться атрибут состоянии приоритеты сроки там нахождения то есть кнопки какие какие будут видны на этом этапе настройки отображения группа которым это видно то есть мы сапожник показываем подметчик не показывает для заявителей для того кто инициировал этот процесс вот и у нас есть матрица
матрица значит матрица связности это такая вот штука которая показывает из какого состояния в какой можно переходить и какие у нас появляются правила вот здесь у нас питоний код здесь данном случае 1 равно 1 мы поставили заглушки проверять сколько какие поля заполнены не заполнены на какую команду происходит назначение как что будет если нарушится условие нахождения на этом этапе как
отработать правила эскалации что оно сделает я могу здесь написать и то не который мне мой документ, например, через два часа провисания в каком-то состоянии, немедленно отправит его начальнику.
Спикер 1:
Получается, это интерпретатор конечного автомата, если это правильно назвать. Да.
Спикер 2:
Здесь есть движок, который работает, постоянно молотит и проверяет в каком состоянии у нас какие документы и что с ними можно сделать. Особенно он любит перетаскивать их состояние на состояние в зависимости от правил перехода.
Спикер 1:
Где-то описан набор операций или что-то потому что у тебя же есть ручные операции по кнопкам да у тебя есть автоматические операции у тебя есть операции по условиям операции по состоянию то есть переходы по ну то есть переходы по времени по таймеру ну допустим этого тоже сейчас пришло в голову, да? Что у тебя неизвестно две ветки, ты пошел по ветке по кнопке.
Ну как раньше, когда все было кнопками, ты описал кнопки, на каждую кнопку ты навесил переход, и на каждую ветку ты навесил функцию, что во время этого перехода, что выполняется. И на этом все закончилось. А сейчас мы понимаем, что у тебя переход может быть по таймеру. Ну условно. И по таймеру, да-да-да. Вот.
Спикер 2:
Это как раз здесь учтено, что раньше были переходы по кнопке на ручном приводе, а сейчас мы что у нас появилось правило переходов. Здесь вот ход, что должно произойти, что вот как только вот это условие, которое я написал здесь, будет истинным, тогда произойдет переход. То есть отработает вот это правило. То есть если, например, у нас из одного узла мы можем перейти в три разных, у нас, соответственно, три разных правила.
Спикер 1:
Какое выполнится, в такое и перейдет. Самая страшная история, а насколько это портируемая история, понимаешь, что если мы маршрута, ну, написали некий гиперграф, да, или еще хуже, его часть, да, то мы можем, должны, ну, понимать, насколько красиво и насколько безболезненно мы можем его перенести в другую часть. Ну, вот ты написал SLA, да, приходит тебе компания, у них почти такой же SLA, но только этими перламутровыми пуговицами.
И вот как перенести вот этот SLA в другую систему?
Спикер 2:
Да, это кстати маленькая проблема. Мы с ней уже столкнулись. Она просто переносится экспортом обычным. Вот эту вот всю матрицу перекидываешь, тут очень мало компонентов, мало базовых моделей. Мы можем взять, скажем так, наши вершины, можем их перетащить экспортом, можем сделать матрицу и перетащить. У нас на самом деле здесь еще подводный камень хитрый.
Вот как вот работают у нас в клетках ДНК и РНК. ДНК никогда не трогается. К нему подходит, соответственно, копировщик и делает РНК. И уже по РНК делаются белки в клетке. У нас здесь точно так же у нас базовые гипер графы они прибиты гвоздями они как днк их нельзя менять как только у нас инициируется новый процесс мы копируем шаблон и уже он начинает жить своей жизнью он даже
мы прогнозировали так что определенный момент как бы самоизменяющийся граф то есть зависимости от состояния он может себя там ходу подпилить вот убрать лишние ветки и документы отправить например совершенно другому маршруту вот это уже все сделано, а кто хочет внедрить себе такую штуку тот должен задонатить в наш консорцию потому что
это будет штука перенесена в консорцию очень ресурсоемкая мы на нее потратили больше тысячи часов вот, но слн они работают это вот что касаемо этих маршрутов универсальных, а что касаемо сигналов это вообще ничего не сделано мы тоже собираемся консультами сделать передачу управляющих команд. Потому что сейчас все сделано по типу вот запускается планировщик, он выполняет какие-то запросы в базе данных, находит что там можно поменять, подвинуть, сделать и выполняет над ними действия.
Это вообще неправильно, вот это контрпродуктивно скажем. Это по старинке. Должен проходить управляющий сигнал как молния через всю систему. Вот, закрываю я сюда доступ, перейдем на эту вкладку выше.
Так, коллеги, еще вопрос, а то мне пора, наверное, заканчивать.
Распознано с использованием https://speech2text.ru