|
LSVИ так некая "стандартная" система одинаково хорошо автоматизирует "ларёк" и машиностроительный холдингНекий стандартный конструктор подобных систем. С готовым качественным набором хороших кубиков:
* наличие своей прикладной IDE, визарды, позволяющие полувизуально делать доработки.
* удобные и наглядные SQL-структуры.
* управление справочниками, списками, менюшками, аттач-файлами.
* управление атрибутами документов (EAV ?)
* управление доступами.
* репортинг, импорт/экспорт, ETL.
* готовый прикладной ф-л (юзеры, контрагенты, преднастроенные must-справочники)
* готовые прикладные куски для популярных задач: SCM, WMS, CRM, HR, Payroll.
* работа с популярными СУБД.
* прочие мелкие удобства: обмен сообщениями, ошибками, автообновление, локализация и т.д.
* разумная ценовая политика для конструктора.
Собственно всё.
На базе такого к-ра можно создать практически бесконечно расширяемую учетную систему.
Ничего фантастичного, правда ? :)ПМСМ, идея сама по себе, конечно же, красива. Вот только на практике не реализуема. Вроде коммунизма. Можно строить-строить-строить, а он так и останется идеей.
Соединять кубики не получится по одной простой причине. На каждом предприятии разные критерии существенности информации разного рода. Кубики должны нормально работать как в случае, когда они состыкованы, так и в случае, если в их коллекции отсутствует какое-либо звено. И не только звено, но и в рамках одного отдельно взятого кубика его использование для одного "сорта бизнеса" может повлечь детальный учет какой-то особой информации, а на другом предприятии собственно кубик нужен, но немного для другого. И никто не готов убивать кучу ресурсов на то, чтобы в системе оказалась информация, от наличия которой нет никакого проку. Вот, скажем, планирование использования технологического оборудования должно учитывать плановые ремонты, для чего должен присутствовать "кубик" ТОиР. А если его нет? Или вот еще... Кубик есть, но нет намерения заниматься планированием до отдельно взятого станка. А если оно есть, то у этого желания есть какая-то причина!.. И если оно есть, то одних только плановых ремонтов может оказаться недостаточно, нужно отслеживать "рабочие точки" оборудования, снимая с неких диагностических датчиков показания практически в "онлайн". Нужен функционал, который позволяет выявлять отколонения и предотвращать отказы оборудования.
Проблема как раз в том, что степень существенности той или иной информации врядли можно унифицировать для всех видов бизнеса. Важно понимать, что отдельно взятый кубик, точнее, функционал этого кубика, может работать только исходя из предположения, что на его входах имеется полноценная достоверная информация. Если кубик нацелен на качественную обработку детализированной информации, то он просто не сможет работать с загрубленной информацией или с ее отсутствием. В этом и заключается главная проблема "кубичной" проблемы. Унифицированные кубики будут требовать ввода информации до такой степени детализации, которая для многих бизнесов будет выглядеть как "маразматическая детализация", не имеющая никакого смысла. Когда же происходит загрубление информации (а оно происходит ВСЕГДА!), возникают специфические для каждой конкретной ситуации модели и предположения, некие аксиомы, который заведомо унифицировать наврядли возможно. Потому что загрубление информации автоматически приводит к снижению ее качества, достоверности, но только в данном конкретном случае известно, до какой степени и за счет чего. На каком-то участке, может быть, имеется некий начальник цеха или мастер, который способен безошибочно сам принимать какие-то решения, и руководство знает, что этот человек никогда их не подведет - так зачем же заствалять сотню других людей бороться с детализацией информации, если она уже побеждена одним-единственным человеком? В другом случае придумывается некая схема взаимного контроля, которая лежит вне плоскости автоматизированной системы... В третьем еще что-то... Как это всё можно унифицировать? Как добиться того, чтобы система не требовала вводить не очень существенную для данного конкретного бизнеса информацию?
У меня есть свой ответ на эти вопросы. Унификация и кубики - да, они должны быть. Кубики должны быть "операбельны" для работы с ними теми людьми, которые отвечают за бизнес-функции и бизнес-процессы (то есть, не только для специалистов-кастомизаторов ERP-систем). Но это не готовый функционал. Это инструменты моделирования бизнеса, базирующиеся на построении информационной модели бизнеса, структурной модели бизнеса, процессной модели бизнеса и его проектной части. И все эти четыре составляющие должны взаимно проникать друг в друга и формировать сразу же действующий функционал автоматизируемых систем, которые опираются на четтыре взаимно проникающие модели одного бизнеса.
Я давно на эту тему свой мозг чешу. И кое-что уже начесал... :) Более того, я теперь хочу найти площадку, на которой смог бы развернуться со своими идеями. Можно создать революционный продукт, который просто не имеет аналогов на рынке систем автоматизации. За базу хочу взять какой-нибудь уже готовый продукт, в котором уже реализована существенная часть того, что должно быть реализовано.
|
