集成应用软件，作为现代化企业发展的基础，已经在各个领域方向有了一定的积累。作为同属于企业基础应用软件供应商，从2007年起，一直按照市场需要调整着产品与方向。从最早的仓储系统到面相合同的R3到R11版本，再到当下的合同/案件/法务/风险/合同为一体的多维度系统化的产品，产品体系在变化，但企业盈利能力却依旧较低，而客户的满意度也没有改善。这是为什么呢？
2015年7月，进入团队时成了“救火队长”，在对产品进行了三个月熟悉与绘制了好几百张逻辑图后，主导了工作流产品走向了可预知、较为稳定的R9版本成型，并在2016年1月底成功在珠江新城的某家公司成功落地，落地后产品维护事项降低了80%,由原有的两个的专人运维到偶尔的运维支持。
这是为什么？产品的稳定性在完成它应有的工作，而临时断电/网络/集成系统引发的问题无法通过产品的稳定性进行修复。作为甲方，肯定需要供应商对相应的事项进行保障，这成了我们实施团队的一项任务，没有工具时必须分析问题并操作数据库，让一些风险转嫁个实施人员。解决问题时间长，风险高，怎么可能提高客户的满意度......
商业是先有->再好->再优的过程。行业的发展，领域模型的成熟，供应商间对领域模型的理解基本接近。而差异会出现在产品对实施/定制扩展/运维能力上，其他基本不会有太大的差异，或者说差异能快速弥补。
企业集成管理软件的发展在哪呢？业务组件化，模型内聚化,微应用化；并在这基础之上，提供完善的运维配套。
软件供应商的最大投入在简单重复的运维事项上，因为产品的生命周期中70%在日常运营中。
经过三年的改造与发展，2019年提出运维工具优先策略，大家不以为意，但却在抽时间做的运维工具中享受着快速运维带来的好处.....
2020年，“黑天鹅”事件改变了发展方向，我们强转java方向，从0起步到当下较为完善的产品体系。在负责的工作流产品方向，基于个人的意志对运维能力进行了加强，当下我们的产品中，工作流方向的运维基本由了成型工具。
而我的团队在做协助支持时，很难接受其他团队无运维而引发的多次/重复配置工作。功能迁移能力太差而无法实现对经过测试的业务提交到生产环境中......
大量的内部消耗，低下的绩效产出，已成为不能接受的事实......
所以，如果我还在公司，将以团队的名义强制推行运维优先策略，提供完善的运维能力后再推动产品上下.........
2022,如果我还在公司，开发小伙伴们的关注点将需要调整了...............
赚钱是工作的目的，而不再是简单的完成工作而已................
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
