我常常在想：如果我们重新开发一次，我们会如何做呢？
所以我常常以这样的问题看ERP3.0。
一、表结构设计
我们表命名应该具备什么规则好找表？表命名规则能解决咱们现在什么问题？集成项目这次做了一些很好的探索。
我们的字段命名应该遵循什么规律？这次组织结构调整方案设计就遇到了这个问题，同样的一个东西在各个表的命名都不一样，所以无法做成统一的规则来应用。
我们的表是否要给数字、字符字段加上默认值。默认值加上什么好？应该不应该加不可为空？不加会有什么问题？说说稳定性、寻找BUG容易程度、升级简易性、性能这些方面的影响。
我们应该使用什么字段类型？字符还有char、varchar、Nvarchar，我们在什么情况下使用什么类型？数值还有int、decimal、money等等，怎么使用？我们的日期还有date、time、datetime、smartdatetime。这些有什么区别，如何适当使用？我们要有标准。
我们的VIEW目前是滥用的。但如何不滥用呢？VIEW应该如何设计才是大小适合的呢？这全都需要研究，做实验验证，找真实功能模块进行改造和测试。然后才能形成标准，然后传递给产品开发、项目开发。
我们的SP虽然是SQL写成，但这也是代码啊。这里面的代码不好调试，而且容易被多个人修改，还不知道是谁修改的，它又不像VB代码可以放到VSS版本管理起来。我们如何恰到好处的适用SP？我不希望云云，拿出数据统计，拿出代码验证。每个事情一深究都有很深的思考。
我们该使用数据库自定义函数吗？我们这次性能调优发现我们数据库设计，在数据库自定义函数这里有性能问题。我们是该禁止大家使用数据库自定义函数吗？如果不禁止，我们如何适合做呢？
我们为什么要禁用触发器？摆事实讲道理，别跟我讲业界大道理。大道理大家都知道，大家用我们目前的ERP中的代码和问题来说证据。另外，我们系统采用了不少触发器。这些触发器如何改造成普通代码。如果要取消某个触发器，怎么能评估这种改动影响，如何保证稳定？都要真实代码修改做验证。
我们的业务其实是具有规律性的。那我们的索引和包含列就应该具有规律。但应该是怎样的规律呢？
总觉得咱们现在的业务、用户量、数据量都不大，所以应该是没有性能问题的，不用测试出来才发现性能问题，而应该在数据库设计的时候就能保证性能。所以我们非常需要研究如何设计表结构和索引。需要研究出规律。
二、项目代码分离
我们希望项目代码和产品代码分离。这样项目定制开发发生的BUG不会扩散到产品代码，而且产品代码出现的BUG，产品发出的补丁可以给全国客户统一升级。
但是怎么做到项目代码分离呢？
另外，如果做到了，我们下一步面临的就是让产品补丁自动检测、自动通知、自动下载，甚至自动升级。产品补丁会包含哪些内容呢？如何做到这一切呢？
尤其我们面临诸多的奇怪的路由器路由、交换器虚拟端口映射、安全防火墙，我们真的能适应各种环境吗？我们如何验证在各个环境都能跑通？
三、分离部署
我们希望每套系统一个数据库，一个web站点，这样关联性交叉行最小。这样性能、稳定性都会好。但是，我们系统之间有业务关联。面对现实和理想，我们应该再下一代如何做才能做到各个子系统的数据库分离、WEB分离，而且业务还能关联。我们需要分析两个关联最紧密的两个子系统，然后真实改造一次，我们才能知道我们的想法是否能落地。
尤其哪些跨三个系统以上使用的数据，他们怎么办？他们在哪里维护？是否要集中维护？如何同步给各个子系统？同步的底层技术框架是什么？是否是消息中间件？还是SQLSERVER自带的主数据同步工具？
什么是主数据？跨三个子系统调用的东西是否是主数据？主数据如何区分？
主数据是否要统一确定的编码规则？什么样的编码规则是可以满足组织拆分合并时灵活使用？
四、统一门户
我们现在有项目运营门户、EKP、企业决策运营门户、ERP主控台。我们现在都是不同的代码，有的是差异比较小，但也是各自一套代码。我们不希望我们出现这么多门户代码各自为政
我们想统一全部门户。但怎么统一。
五、报表与图表
我们现在的报表还是PB报表和RTS报表1+1模式。这是一种妥协方案。一个正规的平台不可能出现多种不同的报表方案。我们在项目中给客户定制了那么多报表，我们有无办法全部自动转换过来
六、收支交易、金额
我们目前及未来会越来越涉及到泛财务范围内的业务处理系统。我们目前的成本、费用就很明显。但是我们目前没有太多财务软件或计费软件研发的经验，因而咱们的设计要保证金额正确、勾稽关系正确比较困难。
我们应该去学习财务系统或计费软件的设计方法，保证我们的交易完整、正确、金额严谨。
七、工作流服务
我们现在遇到了好几起客户，面临我们的工作流和OA系统的工作流要融合。其本质是我们的工作流某些功能不满足客户需要了。我们都需要收集起来，然后统一分析，然后给我们的工作流好好大升一次级。
我们的工作流目前和我们的组织结构绑定太死。我们如何解耦？
我们的工作流如何对外提供集成服务？应该如何设计接口？
我们的工作流表单定义不灵活。如何灵活？
我们的工作流流程设计太麻烦，如何简单？
我们的工作流需要回写数据。如何让这种回写数据解耦，最好也能自定义。
我们的工作流如何按不同部门不同类型划分维护权限？我们的工作流如何进行效能分析？我们的工作流如何满足内审需求？内审需求是什么？
这些都需要我们研究
八、对外集成
我们希望我们的系统成为主干系统，让其他的第三方应用集成到我们这里。
如果第三方集成，我们应该开放什么？
我能想到的是组织结构、用户、权限、工作流、表单、消息、报表、主数据（应该包含哪些主数据呢）
开放需要标准，我们的数据实体中应该包含哪些业务属性字段呢？在技术实现上，这些数据实体应该落实为什么描述方式？XML？JSON？
我们的开放接口如何设计才能灵活应对第三方集成？我们的接口如何遵守契约保持稳定？我们的接口如何应对未来未知的扩展性？如何扩展？如何避免接口的不稳定？
我们提供的接口技术实现应该支持哪些标准？WebService? WCF? REST?
看来我们还需要看看那些开放平台Open API的设计模型，学习人家。
建议我们也学习如何与淘宝API、微博API进行交互，做些DEMO，这可能会是我们客户关系管理、会员管理的一个创新突破点。
九、功能授权、数据授权、岗位多角色
我们现在功能授权无法授到每个按钮每个链接。
我们现在功能没有按岗位角色组织，让一个人面对咱们系统不知道处理他现在的业务需要点击什么模块。
我们现在的数据授权我们还没有通用的方式，只是针对个别点来个别针对。
我们还不能给一个岗位赋予多个角色，尤其是行政组织、专业线组织、虚拟临时项目组织，这三类组织如何统一处理，我们目前还没有想透。
十、并发
我们现在功能有并发需求，但我们不知道如何合适的处理并发，只是在个别点针对场景处理了一些并发。但是我们这次在性能测试、数据异常分析上发现了许多是由于并发没有保护处理导致的问题。这块我们也没有研究通用并发处理方案。需要研究。
十一、业务模型兼容性
我们现在每个版本都增加或完善一些功能，而且每次增加或完善的时候不做全功能分析。也就是说，我们现在一个子系统有多少功能，每个功能有多少场景分支，谁也不知道。
我们目前在一些细小的地方已经发现了某几个场景分支如何真的被客户触发了，就会走入一个非常奇怪的数据流中。这样的数据异常我们很难找到根源，很难修改，最后不了了之。
我们每次增加或完善功能的时候如何做到可以很容易审视到业务模型、业务流程、业务场景的兼容性？
我们跨版本集成之所以难，有的是我们瞎交叉，有的是多层交叉，有的是接口不关心跨版本兼容性随便修改接口，还有一部分就是我们业务模型不兼容，我们现在还不容易找不到，测试到一处才知道一处这处在跨版本集成后是跑不通的。
我们这都得开展研究，如何快速找到业务模型不兼容处。
十二、简化代码
我常说，我们现在的子系统代码写多了。子系统代码写多了，就意味着我们的平台太不给力了。
一个好的平台应该是让上面的子系统少写代码，更好的平台可以让上面的子系统写的代码都具有灵活可配置性。这两个我们目前都没有做到。
如何做一个好的平台呢？我们到底多写了什么代码？我们如何少写这些代码？我们必须完完整整的阅读两个子系统的源代码，才能知道我们如何少写代码？
我们哪些东西应该放在平台中，哪些应该放在公共中？哪些应该放在应用类库中？哪些应该做成代码模板？
怎么做？
十三、组织结构调整引发在途业务数据调整、历史业务数据调整
咱们现在组织结构调整工具的方案还是比较临时妥协的。正规的、彻底的解决方案是什么？
我们知道我们的根源是设计表的时候没有按照业务对象去分析去设计，所以我们的表很散，所以需要针对每个业务进行特定的调整规则。
但是，我们的系统应该如何按照业务领域分析，按照业务对象去设计？
我们需要摸索这样的设计方法。而且如果真采用了这种设计方法，我们的现有功能如果要实现，写SQL容易吗？写VB代码容易吗？性能有问题吗？组织结构真的好调整吗？
另外，我们的组织结构调整无法保留历史快照。我们调整的时候会更新过去的历史数据，这就会造成我们再要打印一张去年的报表，和去年年底打印的那张纸质报表再对应将对应不起来。这就是我们无法历史回溯。
我们如何设计表结构才能做到历史回溯呢？如果要历史回溯功能，哪些业务需要？表应该如何设计？我们的编程是否会更加复杂？是否会影响性能？我们能否在底层平台做统一处理呢？
这些统统的都需要我们研究
十四、数据存取层
我们知道现在这样VB代码和SQL代码搅合着写不好（不好吗？有什么不好？再反问一次）。但是如何把VB代码和SQL代码分离？因为咱们大量SQL语句是动态拼的，是根据判断条件不同而动态拼不同SQL，如果VB代码和SQL代码分离，应该如何实现业务需求呢？需要实际改造几个模块才能找到感觉。
十五、报表
我们知道现在的报表性能慢，占磁盘IO，我们目前采取的方法是隔离报表，也就是把生产数据库和报表数据库分离，用SQLSERVER事务复制的方法来同步两个数据库，然后让报表数据库单独跑在另外的存储设备上，不占用生产数据库的IO。但是，我们这种方法其实在回避或缓解问题，而报表依旧很慢。
虽然我们又做了改进，可以报表晚上任务调度跑然后通过订阅定时发邮件给客户。
虽然我们做了改进，用RTS引擎，这个引擎性能更高，而且支持一个报表多个数据源取数，这样就不用我们为了写一条SQL语句反复绕弯引发性能问题。
虽然我们做了改进，让报表取数最好从基表取数，而不要使用那些缓慢的大VIEW（字段多、关联表多、出来的记录多）。
但是如何让报表快起来，我们依然是问题。
很多时候是我们表结构设计的问题。导致我们的SQL出现大量的子查询，UNION，CASE。但我们如何设计我们的表结构，既满足性能又满足业务需要，又满足写SQL简单呢？这需要研究，并找一个现有模块重新实现来证明这样设计表结构确实性能好、SQL简单、也满足业务需要。
我们还希望设计报表统计层，每日任务调度来产生报表所需数据，这样速度也很快了。
但是哪些报表、多少报表是统计报表？他们目前的现状性能如何？他们是需要即时取数还是可以隔天看数据？如果对照他们设计报表统计层，我们的报表统计层应该是个什么样子？
现在报表、统计报表、查询报表、屏幕报表、功能、查询功能有些不分，我们都把它们统一看待，要纳入到研究范围内。
十六、跨多个浏览器、遵守标准
我们希望我们是跨浏览器运行的。我们现在不行，但怎么做才能行？怎么来证明这样做确实可行？拿我们现有的模块完整的修改一个模块我们来证明。必须这样来证明，而不要做DEMO，更不要看一些文章。我们要拿代码说话。
我们希望我们的ERP能跑在ipad上。ipad屏幕比PC小，ipad键盘不方便，大量需要手势触摸，我们如何改进适应客户使用？
业界WEB标准是什么？我们应该如何遵守？
从我们目前现状，如何走向标准？分为哪几步？我们如何走出一步步？
还有我们的插件，比如客户端打补丁了，IE升级了，OFFICE升级了，WINDOWS环境换了，我们的插件就莫名其妙出现问题。如何减少插件依赖，更重要的是如何逐步取消插件，如何代替插件，这也需要研究代替方案和改动风险、改动成本。
十七、编程方式
我们现在不管做产品还是项目定制开发，都是在现有源代码基础上直接横插一杠子，这就非常容易破坏过去本已经稳定的经过测试的代码场景流程。而且咱们一线常反映这样的需求，说某某客户已经实现了这个功能，我现在这个客户能不能用。答曰：不能，因为代码不好移植。
我希望咱们代码每次增加完善功能的时候是采取桥接的模式。就是你新完善的代码另外写一些函数或干脆在新的一个源代码文件中，然后再想办法和现有的代码对接起来，而不要直接侵入现有代码。这需要有设计模式的编码能力。只有这样才能解耦，才能保持持续稳定，才能保证咱们每次只需要测试改动的这部分就OK。咱们现在测试已经每个版本要花费3个月时间了，但仍然在实施期间发现不少BUG。就是我们子系统代码缺乏架构设计，最根本原因是缺乏实现设计，也缺乏实现设计方法。这都是需要探索的。
我们希望我们的每个功能模块是插件式的，这样项目开发做的模块才好容易给其他客户移植。如何成为插件式的呢？
我还经常说，你们要写函数，要写流程函数和功能函数分离。但是呢，很多人现在连函数也不会写，业务多复杂代码就多长。我也想反复强调也没有用是为何？经过观察是大家都不知道如何做。道理明白，但真正做不知道怎么下手了。所以这个我们还得去研究。
更多人是前台后台代码不分，不知道如何分，不知道哪些代码应该适合在前台写，哪些适合属于业务中间层。我们没有经验，所以强调也没有用。所以只能先让一部分人去研究，去拿现在的代码去改造来证明确实可以找到规律了，然后再制定标准，推广给所有的产品开发人员和项目开发人员。
我们以后还想面向接口契约分析、设计、开发，这也需要研究。
十八、输入输出规则校验引擎
我们目前UI元素之间的控制、输入约束都是用JS写的。代码不容易写不容易读不容易发现错误。输出根本没有约束对与错不知道。
我们为什么不能做一个输入输出规则校验引擎。把规则在引擎规则中写好，然后每个页面在输入保存或输出之前进行引擎校验，这样就让错误的数据不会输出和进入系统。而且规则集中管理，多个入口进行同一个数据操作的就能统一来处理。咱们目前就形成多个入口写的校验规则不一样，因而出现有的页面能保证正确数据，有的页面就允许异常数据也能保存，因而造成系统很奇怪的不稳定，无法重新错误，最后不了了之。
十九、设计
咱们现在经验不足，不知道如何提炼公共功能，也不知道如何提炼公共表。因而瞎提炼，最后就是因为这些瞎提炼的公共功能、公共表老是修改，因为它要满足多个功能对这个公共功能的调用。而这恰恰形成了不稳定性。公共功能一旦不稳定，其他调用的功能都会不稳定，这也就是咱们有时有些模块改一处动全身的原因，这就是一线认为只改动一点项目开发说需要同步开动许多点的云因。这都是我们设计没有经验。但如何提炼公共功能、公共表呢？这就需要研究。目前因为大家经验不足，所以我目前不让大家提炼了，宁可冗余，也不要弄巧成拙。直到我们能驾驭了提炼，我们再去提炼。
我也常说，要把一般场景功能和特殊场景功能分离。但就是不分离。因为我们没有研究，不知道如何分离。设计人员也想分离，但在项目中工作就是不知道如何做，也没有时间多想，因此又退出了原路。所以我们需要一个team持续研究如何真正能够让设计把一般场景和特殊场景分离。
二十、预警引擎
我们现在的ERP，对于管理人员来说不好下手。管理人员最应该做的工作是根据量化的现状进行计划的制定、计划的过程监控。而监控就不必要每天看看各个功能。最好的方式是可以灵活制定预警规则，达到阈值就预警，不同优先级、严重级、类型的预警，可以通知给不同的管理人员。这样就能做到没事不要看系统，有异常会自动通过短信和邮件进行提醒。
这就是我常说的Live ERP，即活的ERP。
二十一、异常捕获框架
大家随便阅读一下我们的源代码，我们的每个功能模块的开发人员都得自己处理异常，而且每个人的经验不同处理方式也不同，有的人是瞎处理，报给客户的错误也可笑，有的是处理的不严密反而引起新的错误，有的干脆把错误自我消化了不让错误报出来，这都是不会写错误处理代码的功底。
我认为子系统是为了处理业务的，它的代码不应该包含系统类型的代码，所以异常处理代码就不应该散落在各个模块自己处理。所以我们应该在平台统一处理异常，这样大家看功能代码的时候就很赏心悦目，只有业务代码业务逻辑而不会让异常处理代码干扰你的思路，这样代码写的少、稳定、易阅读易维护。
二十二、日志
目前咱们日志系统还无法记录太多的数据异常、IIS WEB 异常、性能指标、操作轨迹。我们为什么测试人员老是测试不出深藏的BUG，我们的性能测试人员测试完到客户那里一使用很容易就出性能问题，就是因为我们对客户的使用习惯使用频度使用方式不知道，因而我们都是想象的方式测试，根本不是客户真实使用。
我们希望日志记录下来，自动上传回来，然后大家拿这些数据统计来分析，进而去指导我们的功能测试和性能测试。我们拿数据说话，我们不要自己瞎想瞎设计场景，也不要再让产品经理拍脑门了。
有了这个日志，我们的易用性也知道怎么改进了。一切拿数据跟踪来分析。
二十三、测试
我们目前测试效率低、测试不了解场景、测试却测不出BUG，还有许多不知道如何测。
我们以上列出了二十二个需要未来开展的研究专项，这些都是在架构平台层面的进展。这些专项如何测试？这是摆在我们测试人员你面前的一道难题。
当然，这些二十二个专项也是我们现有开发人员从未想过也不知道如何处理的问题。现在咱们大家都在一个起跑线上。我们大家都在没路找路。所以测试人员也不要害怕自己的测试能力不足或者自己没有技能会不会不适应公司发展。不要这样想。我们都在探索，都在努力摸索，在实践中一点点抠、想。路是我们自己找到的，踏出来的，我们就是在解决问题的路上而能力成长的。
我们要做的的最现实的方法就是测试人员真正一对一对口投入进来，作为一个专项的一员参加进来参加全程，和开发人员一起思考、探索、尝试、验证、交流如何解决这个专项、如何测试。因为我们是一个团队，我们是一条船上的，我们这个船的所有人都是为了攻克这一个专项的。大家需要这样的向心心态和敢于迎接问题的勇气以及密密排查的细心。
如果我们不想透这些问题，并切实找到解决方案，并在实际中证明这个解决方案确实可行，我们有何信心重新开发下一代呢？
谁有信心和思路解决这些问题，谁就站出来，你提你需要什么资源，你说你想怎么干，都提出来，OK，我们一起认同，咱们就开干，你就是这个专项的项目经理和带头人，你就是Owner。
Just Do it! 百无禁忌！激进创新！