ERP CRM系統，結合人工智能方法研發新一代erp系統。
目標，就是開發和維護 實施成本大力降低，軟體性能和質量提高很大。
同時更好滿足erp的通用型，行業通用型，企業個性化需求。
uj5u.com熱心網友回復：
高度概括配置化erp平臺應用程式
=演算法 +資料
=眾多核心微演算法 +個性化演算法 +業務配置資料 +用戶資料
=眾多核心微演算法 +個性化演算法 +業務配置表及資料 +用戶表及資料
=眾多核心微演算法 +個性化演算法
+業務配置表定義 +業務配置表資料
+用戶表定義 +用戶表資料。
其中，
1 眾多核心微演算法、業務配置表定義，相對少變。
核心微演算法，就是軟體的精華部分，
需要前期投入很多的精力時間研發測驗，
而后續作業量很少，主要是修補問題或增添新的。
2 個性化需求演算法，是隨機需求演算法實作，很少且要硬編碼實作。
3 業務配置表資料，可以事先做好模板資料，
遇到實際企業需求，可以根據情況修改資料。
4 用戶表定義、用戶表資料、可以事先做好模板表，
遇到實際企業需求，可以根據情況修改表。
配置化平臺成熟以后，
遇到同類相似客戶，經過需求分析以后，
需要二次開發，主要花費較多時間在：
1 修改業務配置資料。比較容易。
2 設計用戶表結構。 比較容易。
3 個性化需求演算法。 稍微有點難。
而不用反復關注復雜的核心微演算法，
這樣開發測驗上線速度很快。
再往前看，就是預先設定要各種行業的配置化模板，
然后結合用戶要求去快速二次定制，
這樣擴展發展成本比較低，商業上有很強競爭力。
uj5u.com熱心網友回復：
配置化ERP是人工智能？OK:
數我愚鈍，你說的我不懂
嗯涉及到計算機原理
軟體編程、資料結構
CPU 記憶體 網路
當然還有企業管理 財務管理 人際關系 資金管理 身體管理
團隊管理 要熟悉這么多，才可能出配置化erp系統
簡單理解，就是ERP軟體企業的精細化，創新發展的思路
程式 =演算法 +資料
演算法就是就是程式檔案和CPU
資料就是資料
程式檔案，是特殊的資料檔案，送入到CPU后，
就轉化為指令，指令去讀取各種資料，進行計算，然后輸出資料
模擬計算器開始，但離人工智能比較遠
配置化ERP，就是精細化軟體，有點類似人工智能了
通過微內核演算法的強化功能，
然后放入大量各種行業的業務配置資料，定義用戶表，
就快速完成erp專案的開發和實施。
所以往大了說，配置化erp平臺開發，
就是erp系統在往人工智能方向上發展了，不在‘傻傻乎’走老的開發路了。
配置化ERP平臺開發和擴展用途，就是微內核，
大量的不同配置資料，發展思路和人工智能類似的，
比如圍棋alphGO類似，都是有核心演算法，
然后有大量的棋譜資料。
所以一不小心，就闖入了很前沿技術開發和實踐領域
不過肯定也不用太高興，
最多也是ERP系統的初級人工智能，要達到很高的智能，
需要不斷強化核心演算法，
也要用大量資料(業務配置表和用戶表資料)作為基礎。
所以做好erp的初級人工智能，就是很大的進步了。
ERP系統開發，自發 往初級人工智能方向發展
圍棋有段位：業余段位 專業段位，
但出來了人工智能alphoneGo，
最厲害的圍棋冠軍，都敗給人工智能了
:erp也有如此發展方向，
從根據用戶需求的人工硬變編程，朝著人工智能，
演算法和資料分離方向發展。
uj5u.com熱心網友回復：
1101 Erp配置化設計開發思路java版erp，主要技術設計，分資料庫、中間層、界面層。
1 資料庫層，和delphi層類似的設計，以前檔案已經說過。
2 界面層。主要js xxx等開源架構。
1 如果采用運行時，生成動態界面，
讀取配置資料，來動態創建界面控制元件、
讀取配置資料，呼叫js的公共代碼。
非常依賴前端專案自身功能，技術難度很大。
但研發成功后，就不需要頻繁編譯和發布界面，
后期開發和維護很簡單。
此方案，目前不具備技術能力，
另外動態生成界面檔案，也會耗用時間，
讓用戶等待延時，在客戶端多時，并不好。
2 如果據配置資料生成靜態界面檔案，再編譯。
讀取配置資料，創建界面控制元件、和呼叫js的公共代碼，
最后形成各個靜態前端檔案，再編譯、發布。
不太依賴前端專案自身功能，技術難度中等。
主要是寫一個獨立的程式：
根據配置資料，生成一個個界面檔案，
里面有界面控制元件、呼叫公共js(vue)的代碼。
研發成功后，仍需要頻繁編譯和發布界面，
后期開發和維護，相比手工撰寫，簡單很多很多，
相比運行時動態生成界面，開發和配置一樣的作業量，
只是編譯和發布的作業不少。
此方案，目前初步具備技術能力。
另外生成靜態界面檔案再編譯發布，用戶訪問很快。
3 中間層。主要是java spring mybatis架構。
1 資料訪問層的靜態資料類，是OR映射而來，
要么手工撰寫，要么用IDEA開發工具去生成。
2 java語言或控制元件，目前不支持根據表，
動態創建資料物件類或及其欄位屬性。
表欄位改變時，要手工或工具重新修改資料定義類，
及其衍生的處理程序中的欄位名，然后編譯和發布。
因此受開發工具限制，修改表欄位時，
必須去改中間層的訪問層、中間層源代碼，并編譯發布。
那意思是用戶需求變化(表欄位)后，
必須修改中間層源代碼，并編譯、
停用目前系統，再發布程式，再重啟中間層。
那這個是冷啟動中間層，無法做到熱啟動。
熱啟動說明：中間層啟動(中途不停止)，
修改配置資料后，重繪客戶端網頁，就完成功能升級。
3 java 語言為何不開發類似Delphi的資料集物件，
可以動態創建OR映射表的資料集物件，
那樣就不用花很多時間，維護中間層的資料定義類。
java中間層，采用大量簡單物件的原因：
1 客戶端訪問數巨量，每次訪問消耗要小，必選簡單物件。
java專案，面向互聯網應用，網頁客戶端，
幾百、幾千、幾萬、幾十萬用戶訪問量，
每個用戶訪問一次，就復制好幾MB大的記憶體，
用來管理資料集物件(含有很多資料區和函式功能)。
那么平均每個用戶訪問一段時間，
就要耗用至少幾十MB大記憶體，來存放資料訪問物件。
那服務器總需要消耗記憶體，以GB為單位直線上升。
所以考慮服務器記憶體量限制，
不允許使用萬能動態的資料集物件。
2 java 記憶體非實時釋放，而是空閑時才自動回收。
平時白天不能消耗太多記憶體，否則在回收前，就宕機。
java語言為了減少程式員的作業壓力，
和減少記憶體泄露風險，默認不提供記憶體即時回收功能，
而是等到系統比較空閑時，去回收記憶體中的垃圾物件。
這樣如果平時訪問消耗大量記憶體，要到晚上才回收，
那很可能白天記憶體就耗盡了。
而delphi、C++等語言，是記憶體及時回收的，
這樣每次可以創建很大記憶體空間、也很復雜的物件，
來處理復雜的業務，使用完物件，代碼里主動釋放記憶體。
只是實際開發中，尤其是大型系統，多人開發，
代碼量大，可能就會有部分代碼，并沒有及時回收記憶體，
這樣就出現記憶體泄露，記憶體利用率低，甚至發生宕機。
所以java中間層，由于客戶端訪問量巨大，記憶體垃圾回收慢，
每次訪問，消耗記憶體須極度小，必選簡單的資料物件和處理。
那么就不能采用動態的、萬能的資料集(OR)映射功能，
資料集里，訪問欄位，可根據欄位名去動態讀取和設定，
不用事先定義好。
只能用簡單資料類，
那么改表欄位時，就要重新改并編譯中間層。
另外java是強型別語言，不支持動態創建類的屬性。
所以java中間層，不能采用運行時讀取配置資訊，
來構建最新的資料類及時屬性，那么后續的處理也就停了。
那java中間層，還是如其 xxx界面層一樣，
是編譯前，根據配置資料生成java中間層代碼。
另外在delphi unigui開發上配置化erp系統，
則和java開發，在界面和中間層不同，
是可以采用界面 +中間層混雜一起的，
運行時，讀取配置資料，完成界面，呼叫業務邏輯。
其運行的環境條件：
1 客戶端不能多(標準200個)，太多了記憶體耗用量就很大。
要靠負載均衡，增加應用服務器臺數。
2 delphi unigui記憶體回收是實時的，
所以只要寫的好，記憶體不會泄露。
所以經過以上分析，得出erp配置化，
都可以在java、delphi unigui上實作，
都需要依賴配置資料，但后續不同：
1 java版是前端和后端編譯前，
把配置資料自動生成為各類程式檔案。
再手工加入個別個性化代碼，編譯，發布。
2 delphi版是運行時，讀取配置資料，
自動創建界面和呼叫處理邏輯。
個別個性化代碼，需要預先撰寫簡單程式檔案，
再加入個性化代碼。
而頻繁編譯和發布程式，就省掉，因支持熱啟動。
具體如何開展配置化專案：
根據不同平臺的特點，
java版服務端記憶體消耗少，可適應較多客戶端訪問。
較適合人數眾多企業，比如中型、大型企業。
但其缺點，就是前端技術平臺切換快，
中間層設計，不支持熱啟動，
要重新編譯和發布，一般是晚上發布，
增加維護和實施作業量。
而dephi unigui版，很多設計以及優缺點，和java版相反。
我們可以預先設想一下應用場景：
1 給小客戶(100、50人一下規模)提供java版，
改動一下功能，都要晚上發布，
用戶等不耐煩，開發實施的嫌報酬給的少、嫌作業累。
2 給中、大客戶提供delphi unigui版，
客戶在訪問量大時，就會查詢和提交速度會變慢，
然后建議用戶增加應用服務器臺數。
因為網路中斷或合上筆記本螢屏，
再回到網頁時，就提示系統連接失敗，正在連接中。
用戶會覺得其他網頁版不會這樣，這個怎么會這樣。
用戶會提出安全性問題，要求部署到linux服務器上。
用戶會要求開發方技術資質高，比如人員規模要大，
能提供持續服務，那么選擇較少人用的delphi，
就不利于人員規模擴大。
所以根據用戶不同，應該提供不同的版本系統，
才是對的，當然2個版本，都是依賴配置資料，
具有初級人工智能的(演算法和資料分離)。
這樣才會滿足不同客戶的需求。
根據最近一年java版積累、以及以前積累的經驗，
要同時啟動兩個版本的配置化版本開發。
他們的核心思想就是人工智能，配置化，
只是在實作程序，根據應用場景和平臺特點而變化了。
那只啟用其中一個行不行呢？
短期可行，長期不可行。
因為2個版本，分別服務于中小型企業，和中大型企業，
放棄任何一個，就意味著放棄一個未來的市場。
兩個版本，一起做，肯定比只做一個的，作業量大，
應對方法：
1 放慢開發計劃進度，不要搞太快，太累了。
2 "老人"，帶"新人"方式，來加快開發速度。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/244893.html
標籤：ERP/CRM
上一篇：求助，單位域控制器崩潰了，重裝系統，重新配置同名域后，客戶端登錄提示密碼錯誤
下一篇：繪制微信小程式驗證碼