Импортозамещение для ERP — социальная сеть управления предприятием

19.07.22

Архитектура

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

Импортозамещение для ERP — социальная сеть управления предприятием

"Не красиво — не полетит!"

А.Н.Туполев

Введение

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

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

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

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

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

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

 

Описание процессов предприятия

Рассмотрим гипотетическую «Фабрику глиняной посуды» и процессы, связанные с её хозяйственной деятельностью.

Хозяйственная деятельность любого предприятия -  это замкнутая последовательность операций по превращению одних ценностей в другие (авторская интерпретация бухгалтерского учета), например: вначале Деньги превращаются в Материалы; затем Материалы в Продукцию; далее Продукция снова превращается в Деньги.

Рассмотрим, какие процессы «превращения ценностей» применимы нашей  «Фабрике глиняной посуды» :

  1. Поставщик получает рубли, взамен продает предприятию глину;
  2. Гончар из глины вылепляет изящный кувшин;
  3. Покупатель покупает изящные кувшины, взамен отдает предприятию рубли.

Каждый процесс на предприятии проходит пять жизненных стадий — этапов «превращения ценностей»:

  1. Нормирование;
  2. Проектирование;
  3. Календарное планирование;
  4. Распределение ресурсов;
  5. Исполнение.

Рассмотрим каждый этап в отдельности.

 

Нормирование

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

 

Описание спецификации Операция Производимые ценности Потребляемые ценности Продолжительность
Ценности Объем Ценности Объем
1 Стоимость покупки глины Покупка Глина 5 кг Деньги 100 руб 1 день
2 Материальная спецификация кувшина Лепка Кувшин 1 шт Глина 1 кг 5 дней
3 Оптовая стоимость продажи кувшина Продажа Деньги 200 руб Кувшин 2 шт 1 день

 

Полученная табличка представляет собой единый «Журнал спецификаций», в котором объединена информация о разных объектах управления (деньги, материалы, продукция и другие).  Выпишем основные реквизиты получившегося сквозного «Журнала  спецификаций»:

  • Наименование операции;
  • Перечень производимых ценностей (Ценности, Количество);
  • Перечень потребляемых ценностей (Ценности, Количество);
  • Продолжительность операции.

 

Проектирование

Опираясь на сведения из спецификаций, на предприятии составляется сквозное описание проекта деятельности: определяется перечень и объем необходимых операций превращения (производства и потребления) ценностей.  Составим перечень операций в едином «Журнале проекта». Закрепим за операциями ответственные службы.  Количество операций подберем таким образом, чтобы по всем ценностям, участвующим в проекте, кроме денег, общее количество производимых ценностей по проекту совпало с общим количеством  потребляемых ценностей по проекту. Для денег, получившаяся положительная разница между производимым и потребляемым количеством — покажет прибыль проекта, отрицательная разница — покажет убыток проекта.

 

Операция Количество
операций
Ответственная служба Проект производства (расчет по спецификации, справочно) Проект потребления(расчет по спецификации, справочно)
Ценности Объем* Ценности Объем*
4 Стоимость кувшина (продажа) 5 Служба реализации Деньги 1000 руб Кувшин 10 шт
5 Материальная спецификация кувшина (производство) 10 Производственная служба Кувшин 10 шт Глина 10 кг
6 Стоимость глины  (покупка) 2 Служба закупки Глина 10 кг Деньги 200 руб

*в результате расчета по спецификациям получилась прибыль 800 руб.

Выпишем основные реквизиты сквозного «Журнала проекта»:

  • Операция;
  • Количество повторов операций;
  • Ответственная служба.

 

Календарное планирование

Службы исполнители после утверждения проекта формируют календарный план. Приведем пример единого «Журнала календарного планирования». Операции расположим (от последней) в обратном порядке. Даты отсчитываем от итогового дня отчетности предприятия (например, 30 июня).

 

Дата Описание Служба Инициатор Служба Соисполнитель План поступления План выбытия
30 июня Окончательный платеж покупателя Служба реализации Финансовая служба Деньги 800 руб Расчет с покупателем 800 руб
8 29 июня Отгрузка покупателю Служба сбыта Служба реализации Расчет с покупателем 1000 руб Кувшин 10 шт
9 28 июня Выпуск продукции Производственная служба Служба сбыта Кувшин 10 шт 100%
10 23 июня Использование материалов Служба обеспечения Производственная служба 100% Глина 10 кг
11 22 июня Поступление от поставщика Служба закупки Служба обеспечения Глина 10 кг Расчет с поставщиком 200 руб
12 21 июня Платеж поставщику Финансовая служба Служба закупки Расчет с поставщиком 200 руб Деньги 200 руб
20 июня Аванс покупателя Служба реализации Финансовая служба Деньги 200 руб Расчет с покупателем 200 руб

 

В «Журнале календарного планирования» детализация операций по сравнению с «Журналом проекта» выросла в 2 раза — каждая операция «Производство/Потребление» разбилась на отдельные «План поступления» и «План выбытия». «Расчеты с поставщиками и покупателями» и «производство» получили количественные показатели. За каждым количественным показателем закреплены службы инициатор и соисполнитель с указанием плановой даты достижения показателя. Приведен пример (см. 7а и 7б) планирования двух этапов платежей покупателя: Аванс и Окончательный платеж. Выпишем основные реквизиты получившегося сквозного «Журнала календарного планирования»:

  • Плановая дата операции;
  • Описание;
  • Служба инициатор;
  • Служба соисполнитель;
  • План поступления (Ценности, Количество);
  • План выбытия (Ценности, Количество).

 

Распределение ресурсов

Руководители служб инициаторов, после утверждения календарного плана,  раздают материально ответственным лицам (МОЛ) - исполнителям приоритетные поручения и требования для закрытия утвержденных планов (по выбытию и поступлению ценностей). Рассмотрим примеры единого «Журнала требований и поручений».

 

Документ Служба Инициатор МОЛ - Исполнитель Служба соисполнитель Поручено/затребовано Описание
13 Поручение покупателю оплатить Аванс + Окончательный расчет Служба реализации Покупатель Финансовая служба Расчет с покупателем 200+800 руб Отражается в счетах покупателю
14 Требование перечислить Аванс + Окончательный расчет в банк Финансовая служба Банк Служба реализации Расчет с покупателем 200+800 руб
15 Требование оплатить поставщику Служба закупки Поставщик Финансовая служба Деньги 200 руб  
16 Поручение банку перечислить деньги поставщику Финансовая служба Банк Служба закупки Деньги 200 руб  
17 Поручение  поставщику отгрузить материалы Служба закупки Поставщик Служба обеспечения Расчет с поставщиком 200 руб Отражается в доверенности для поставщика
18 Требование поставки материалов Служба обеспечения Кладовщик склада материалов Служба закупки Расчет с поставщиком 200 руб
19 Поручение отпуска (резервирование)  материалов на складе Служба обеспечения Кладовщик склада материалов Производственная служба Глина 10 кг  
20 Требование на получение материалов на складе Производственная служба Мастер на производстве Служба обеспечения Глина 10 кг  
21 Поручение о запуске в производство Производственная служба Мастер на производстве Служба сбыта 100%  
22 Требование о передаче готовой продукции на склад Служба сбыта Упаковщик склада готовой продукции Производственная служба 100%  
23 Требование отгрузки продукции Служба реализации Покупатель Служба сбыта Кувшин 10 шт Отражается в доверенности покупателя
24 Поручение отгрузить продукцию Служба сбыта Упаковщик склада готовой продукции Служба реализации Кувшин 10 шт

 

Выпишем основные реквизиты сквозного «Журнала требований и поручений»:

Документ;

  • Служба инициатор;
  • МОЛ исполнитель;
  • Служба соисполнитель;
  • Поручено/затребовано (Ценности, Количество).

 

Исполнение

Согласно поручениям и требованиям, МОЛ-исполнители осуществляют хозяйственную деятельность (передачу и приемку ценностей), оформляют/регистрируют первичные документы, подтверждающие факты хозяйственной деятельности. Рассмотрим примеры единого «Журнала прихода и расхода».

 

Документ/хозяйственная орперация Основания Исполнитель Факт прихода Факт расхода Описание
25 Закрытие обязательств покупателя по оплате

Поручение п.13

Требование п.14

Покупатель   Расчет с покупателем 200+800 руб Отображается справочно в выписке банка
26 Выписка банка о поступивших платежах от покупателя

Поручение п.13

Требование п.14

Банк Деньги 200+800 руб    
27 Выписка банка об исходящих платежах поставщику

Поручение п.16

Требование п.15

Банк   Деньги 200 руб  
28 Закрытие обязательств перед поставщиком по оплате Поручение п.16 Требование п.15 Поставщик Расчет с поставщиком 200 руб   Отображается справочно в выписке банка
29 Документ приобретения материалов от поставщика Поручение п.17 Требование п.18 Поставщик   Расчет с поставщиком 200 руб ТОРГ-12
30 Приходный ордер на склад материалов Поручение п.17 Требование п.18 Кладовщик склада материалов Глина 10 кг    
31 Расходный ордер со склада материалов Поручение п.19 Требование п.20 Кладовщик склада материалов   Глина 10 кг  
32 Акт списания материалов в производство Поручение п.19 Требование п.20 Мастер на производстве 100%    
33 Акт выпуска готовой продукции Поручение п.21 Требование п.22 Мастер на производстве   100%  
34 Приходный ордер на склад готовой продукции Поручение п.21 Требование п.22 Упаковщик склада готовой продукции Кувшин 10 шт    
35 Расходный ордер со склада готовой продукции Поручение п.24 Требование п.23 Упаковщик склада готовой продукции   Кувшин 10 шт  
36 Документ реализации продукции покупателю Поручение п.24 Требование п.23 Покупатель Расчет с покупателем 1000 руб   ТОРГ-12

 

Выпишем основные реквизиты сквозного «Журнала прихода и расхода»:

  • Документ;
  • Основания;
  • МОЛ исполнитель;
  • Факт прихода/расхода (Ценности, Количество).

 

Заключение

На 36 типовых операций предприятия, мы получили (прототипы) всего 5 сквозных журналов регистрации - объектов для автоматизации:

  1. «Журнал  спецификаций»;
  2. «Журнал проекта»;
  3. «Журнал календарного планирования»;
  4. «Журнал требований и поручений»;
  5. «Журнал прихода и расхода».

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

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

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

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

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

автоматизация управление предприятие универсальный журнал социальная сеть

См. также

Архитектурное ревью. Процесс разработки

Архитектура решений Бесплатно (free)

Рассмотрим применение архитектурной проверки задач в процессе разработки.

30.10.2023    4026    0    ivanov660    10    

30

Я - ЗУПер! Часть 4. Проблемы, возникающие при заключении договоров

Бизнес-анализ Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и Управление Персоналом 3.x Бесплатно (free)

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

07.08.2023    5180    0    biimmap    43    

57

Я - ЗУПер! Часть 3. Ошибки работодателей и соискателей. Плюсы специализации на одной предметной области

Бизнес-анализ Платформа 1С v8.3 1С:Зарплата и Управление Персоналом 3.x Бесплатно (free)

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

19.04.2023    4704    0    biimmap    37    

60

Я - ЗУПер! Часть 2. Классификация проектов и задач

Бизнес-анализ Платформа 1С v8.3 1С:Зарплата и Управление Персоналом 3.x Бесплатно (free)

В первой части рассмотрели компетенции специалиста в сфере ЗУП. В этой статье рассмотрим классификацию проектов и задач на проектах. Классификация построена на моём личном опыте длиною в 20 лет. На неё будем опираться в третьей части статьи.

13.04.2023    3532    0    biimmap    14    

41

Искусство отчета

Отчеты и дашборды Платформа 1С v8.3 Система компоновки данных Бесплатно (free)

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

26.02.2023    3443    0    DemetrKlim    38    

28

RPA для перехода с SAP на 1С

Бизнес-анализ Россия Бесплатно (free)

Зачем нужна роботизация при переходе с SAP на 1С. Как мигрировать с SAP с минимальными усилиями и даже без команд поддержки SAP.

09.01.2023    2299    0    comol    9    

7

Опыт работы «1С:ERP» в ландшафте Linux + PostgreSQL – 7 лет

Бизнес-анализ Платформа 1С v8.3 1С:ERP Управление предприятием 2 Россия Бесплатно (free)

В связи с обострением вопросов импортозамещения многие задумываются о переходе на системы, позволяющие заменить зарубежные аналоги, или уже его начали. Мы решили поделиться с вами 7-летним опытом установки и эксплуатации системы Linux + PostgreSQL + «1C» на 300 онлайн-пользователей.

16.12.2022    7642    0    1СERP    34    

67

Таблица для финансиста. Решение на стыке технологий

Бизнес-анализ Бесплатно (free)

Что будет, если взять от Excel простоту и легкость составления таблиц с формулами, а от базы данных – системность и возможность работы с общими справочниками? Сергей Тангатаров, руководитель направления бюджетирования и МСФО в Инфостарте, на конференции Infostart Event 2021 Post-Apocalypse рассказал о Табуле – решении «на стыке технологий», дающем возможности выполнять финансово-экономические проекты на новом уровне.

19.09.2022    3564    0    Serg_Tangatarov    0    

30
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Lancelot-2M 115 20.07.22 09:02 Сейчас в теме
Тонко. Ждём целеуказание на рекламируемый продукт. Не 1С, конечно.
2. sereginseregin 22 21.07.22 12:49 Сейчас в теме
(1)Централизованные решения (1с и прочие) для унифицированных журналов не годятся из-за производительности RLS. Предпочтительней вариан распределенки, когда у каждого пользователя (группы) своя индивидуальная копия данных, без разграничений прав доступа.

Касаемо готового продукта:
- Опытные разработчики не любят унификаций;
- Середнячки заняты популярными велосипедами;
- Остаются молодые, которым нужны простые и быстрые идеи.

Предложенное решение технически не сложное, но точка входа Agile пока не определена.
3. mixsture 21.07.22 14:15 Сейчас в теме
Чем меньшее количество регистров будет в системе, чем более универсальными они будут, тем прозрачнее будет архитектура системы, проще и дешевле алгоритмизация процессов сбора и анализа показателей предприятия, в особенности, при формировании множества сводных общекорпоративных отчетов.


Но существенно хуже по производительности. Прям на порядки.
Вот под ваше описание хорошо подходит самая наивная реализация пользовательских свойств: присутствует в конфигурациях 1с на обычных формах, регистр ЗначенияСвойствОбъектов и вспомогательные справочники вокруг него.
Этот регистр сведений супер универсальный - в нем однообразно задаются свойства для почти любого объекта 1с, но как это видит движок СУБД? Он видит одну таблицу на десятки миллионов записей, которую в типовых отчетах левым соединением подключают несколько десятков раз.
Из-за того, что все свалено в одну таблицу, оптимизатор запросов не очень корректно может определить селективность каждого значения. Потому что там одновременно присутствуют булевы значения (условно отбор по такому значению выдаст разделение набора данных пополам, т.е. условная селективность 50%) и одновременно "справочники" с 1к элементов (и отбор по нему также условно выдаст 0,1% от набора) - оптимизатор будет использовать некое среднее значение, которое ошибочно с обоих сторон, в итоге будет строить неоптимальный план запроса.

Берем этот регистр сведений, делим его - каждому виду объектов делаем свой собственный. Стало много таблиц, зато оптимизатор теперь в разы лучше понимает селективность каждого значения. (к слову, мы получаем механику хранения свойств, близкую к конфигурациям на управляемых формах).
---
С универсальными мега-таблицами также повышается риск блокировок данных между пользователями (даже в управляемом режиме блокировки захватывают довольно обширные области в пересечениях измерений). В самом плохом варианте это было в 1с7.7: там был единый журнал документов, который изменять мог только 1 пользователь в каждый момент времени (потабличная блокировка), что выстраивало всех пользователей, желающих провести документы, в одну большую очередь. Имхо, это и стало убийцей платформы 1с7.7.
---
Также проблемы вас ждут, когда вы захотите повесить какой-то код на событие изменения свойства. Вам придется ловить их все, а уже внутри кода 1с фильтровать изменения только нужного вам свойства.
---
Еще часто используют денормализацию для ускорения построения отчетов. Т.е. технически эти данные можно было бы вывести из уже существующих, но очень затратно. А мы вместо этого храним некую копию-компиляцию данных, но удобную для построения отчета.
4. sereginseregin 22 21.07.22 18:47 Сейчас в теме
(3)
Берем этот регистр сведений, делим его - каждому виду объектов делаем свой собственный.

Партицирование ещё не пришло в 1с. Но проблему Вашу это все равно не решает, через n-ное количество времени в отдельных таблицах накопится достаточно данных, чтобы осадить производительность
Прям на порядки.

Проблема производительности существует всегда, ее нужно решать, а денормализация данных даст только краткосрочный эффект, передышку на некоторое время.
5. mixsture 21.07.22 22:59 Сейчас в теме
(4)
Партицирование ещё не пришло в 1с. Но проблему Вашу это все равно не решает, через n-ное количество времени в отдельных таблицах накопится достаточно данных, чтобы осадить производительность


Тут наибольшая проблема не в количестве, а в смеси разнотипных объектов. Они имеют мало общего и поэтому путают оптимизатор запросов.

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


Наоборот, денормализация при грамотном применении - один из самых долгосрочных и эффективных. Я не зря написал "на порядки" - это действительно часто в сотню раз ускоряет построение отчета.
8. sereginseregin 22 22.07.22 16:33 Сейчас в теме
(5) В PostgteSQL сталкивался с простыми запросами, в которых индексы отключаются если в выражении in (select ...). в подзапросе набор данных состоял из более 40 записей. При менее 40 записей индекс стабильно включался, собирая данные в сотни раз быстрее.
Следуя Вашей логике, используя СУБД Postgres, стоит избегать справочников с количеством записей более 40.

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

Опыт он всегда полезен. По вашим претензиям есть несколько вариантов решений. Для централизованных систем придумали партицирование. А для распределенных систем такая проблема может вообще не возникнуть.
6. user799587 23 22.07.22 09:38 Сейчас в теме
"Мы находимся в самом начале развития автоматизированных систем" - один из лидеров SAP был создан в 1976 году, не такой уж малый срок. Да и создан был сотрудниками IBM, от есть тоже не с нуля. Различных теорий управления предприятием и производством множество, и не будет преувеличением сказать, что весь 20 век был посвящен созданию и применению таких теорий.
Деятельность людей по созданию ценностей носит очень разнообразный характер, вряд ли можно найти универсальное решение по автоматизации.
7. sereginseregin 22 22.07.22 16:19 Сейчас в теме
(6)
...один из лидеров SAP был создан в 1976 году, не такой уж малый срок...
Это всего 1-2 поколения разработчиков.
Деятельность людей по созданию ценностей носит очень разнообразный характер
А для сложных систем знания и ценности налепляются друг на друга, превращаясь в динозавра, потому что проще и дешевле доработать то, что уже есть, чем развивать каждый раз с начала. Такие динозавры существуют, пока их поддерживают первые создатели. Так что 50 лет - младенческий срок для ИТ.
Оставьте свое сообщение