而解决软件系统需求的方法有三种：软硬系统集成、生态平台合作、完全自主开发。
第一种，软件与硬件的切割非常明显，力求术业有专攻，专业的人做专业的事，大家一起来完成场景拼图，这种方式考验使用者在系统构建过程中的耐心、对行业需求的解读和传递，以及应对各种功能/成本/时间变化的能力，更考验系统集成商的经验和合作伙伴之间的协同效率，是整体方案使用效果的关键一环。
第二种，软硬件厂商进行平台级合作，弹性切割各自的系统边界，硬件厂商继承性地继续做好与硬件强耦合的部分，并延展至自己行业特性需求的小场景APP，软件厂商提供“稳态”的面向整体大流程的复杂系统级应用，并在平台上实现集成，共同形成面向各场景所有利益相关方的业务网络，这种模式下，对设备厂商来说，需要与软件厂商一起，构建针对具体行业、加工类型的业务实践，以供快速高效复制；对软件厂商而言，把设备厂商的行业级APP纳入自己的方案体系，并在同一平台上实现集成，在增加设备厂商收入的同时，有设备厂商作为实例化样板，也会大大增强方案的产品力和接受度。
第三种，顾名思义，由设备厂商自建相关软件系统，且自建软件的种类越来越多，程度也越来越深，究其原因，以ToC业务为主的互联网企业过去倡导的架构中台化、系统解耦化、微服务化的成功起到了明显的推动作用，很多传统的工业企业，在新成立的数字化转型部门、寻求转型拓展的内部IT部门都请来BATH等的跨行业的“和尚”来念转型经。当特斯拉门把传统的驾驶工具变成了可交互的出行终端，实现在汽车行业的逆袭的同时，大肆宣扬自主开发了ERP、CRM……, 这种模式在ToB行业的未来被无限放大就毫不奇怪了，尽管其开发的内部运营系统的好坏仍然是众说纷纭，尽管玩转了OTA操作系统让用户欲罢不能的汽车仍然是一种ToC的工业品。
笔者呼吁，这种趋势应该引起制造行业从业者的高度警惕！
ToC业务的软件系统可以解耦、微服务，核心原因是数据结构足够简单。至少在真正的强人工智能出现之前，ToC大数据的“大”更多表现在相对独立的众多使用场景的海量叠加，从数据处理角度看，这种模式/场景多样性因为不嵌套复杂的流程逻辑，使得数据量只是比较单纯的“大”或者“多”，而不是复杂，业务处理的难度也随之减少。但即便如此，我们也仍然会经常碰到使用场景中各种“相对个性化”的需求得不到满足而造成使用不便、用户体验不好，但因为个体影响力的局限、使用次数的不持续或者是发布方的垄断地位，只能捏着鼻子忍了。
ToB业务有根本不同。当前制造业的服务化延伸或者转型，在选择软件系统的配套方式时，尤其应该三思而后行。首先，不认真考虑业务属性或者说业务架构，不想好基于业务属性的应用架构和数据架构，强行通过打点的方式完成整体的事情，过去金X和用X不行，更加不专业的企业内部IT团队更加不行。其次，自建系统需要有强大的PaaS平台做加持。专业的云原生方案商如salesforce，一个不争的事实是，如果没有.com PaaS平台，其CRM SaaS的产品力马上大打折扣，笔者的一位从业几十年的同事就直言“没有好的PaaS支撑的工业SaaS方案就是耍流氓”。最后，ToB业务的软件解决方案的构建与开发，绝不是先解决0到1的有无问题，再逐步做1-10、10-50、50-100的简单迭代，除非你有每个节点都推倒重来的决心、执行力、足够的钱，且市场是你的专属真爱，永远不离不弃。
