|
![]() |
#1 |
Учаснег
|
На мой взгляд
Идея сама по себе не плоха: соединить средство моделирования (а-ля CASE) со средством разработки OLTP системы, а также поставить сверху некий OLAP с общей со средством моделирования схемой данных.
Однако же - все это было, было, было... Если взять любой русский "бухгалтерско-учетный конструктор", коих я лично перевидал не один десяток - там все то же самое. Сущности, документы, операции... Забр, если ты читаешь это - тебе ничего не напоминает ![]() Проблема, как всегда, настанет у конечных юзеров. Программистов не надо убеждать, что "заказ на продажу - это чей-то заказ на покупку". Но поди убеди в этом тетю из отдела снабжения, желающую иметь заказы на покупку, и только их. С совершенно уникальной технологией обработки при том. Я это к тому, что унификация инструментов управления бизнесом - неизбежно подразумевает унификацию самого бизнеса. Конечная цель состоит разумеется не в том, чтобы предложить универсальную среду разработки ERP-систем самими пользователями: какой смысл экономить на разработке, но потом больше вкладывать в поддержку? Цель (как мне кажется) - заставить обычных юзеров работать не в ERP-системе, в режиме "нажал кнопку - получил результат" - а сподвигнуть их на самостоятельное моделирование, создание work environment под себя. При этом данные будут заноситься в систему в некоем стандартном виде. Очень сильно огрубляя, юзер создаст себе экселеподобную (или 1С-look-like, кому как нравится) форму, пропишет нужную ему логику обработки в терминах предметной области ("взять такую-то сумму, разбить ее так то, поместить туда-то), и все это система автоматически "правильно" разнесет куда надо в базе данных. Далее, другой юзер на основании этих данных создаст сам себе какой ему надо отчет/аналитический куб. Но это требует серьезного переучивания юзеров, освоения ими не просто азов компьютерной грамотности "двигай мышкой сюда-нажимай кнопку там"...
__________________
Strictly IMHO & nothing personal ![]() |
|
|
|