浅谈行业软件

行业软件通常针对性强，特定的垂直领域，特定的应用需求，特定的使用人群，而且通常要解决专业问题，生命周期也长，因此行业软件经过多年的发展，其中必然会碰到一些进退两难的问题。



不能以为行业软件有很强的针对性，其竞争激烈程度就低，在市场环境下，只要明确的可以获取利润，竞争便会逐步增强。行业软件起步应该说要早于互联网，所以早期的行业软件除了文章开头讲述的几个特定外，还有一个特定很重要，又是对其束缚较大的一个因素，那就是通常会有一定的地域性，比如，A公司主要在北京做，B公司主要在广东做，C公司主要在浙江做，而且区域内可能也存在较强竞争，或经过多年打拼成了地方龙头，或形成几强割据共分市场的状况。这是早期行业软件比较容易形成的一种生态格局。



但是随着互联网的快速发展，以及公司自身向更高层级发展的需要，谁家都不甘偏安一隅，一定会向外扩张，就形成了更大范围内的竞争。加上市场开放程度的不断提高，地域之间的政策保护逐步下降，也给行业软件带来更多的有意与无意的竞争，一旦出现行业内绝对优势的头部企业，占据了绝对多数的市场份额，那在这个行业内的中小玩家都会比较痛苦，原有市场被挤压，利润也很难维持在高位。



这也反逼企业要在行业继续生存，必然要进行一些变革，变的方向通常在深度和广度上进行，再一个就是在赛道的选择上进行调整。往深了做，这要求行业知识足够扎实，要精深，或者要求技术上有独到之处，这两点不容易做到，尤其是在行业巨头形成后，人才资源又会倾向向巨头集中，所以在深度上变革困难很大。再一个做深需要的投入很大，都知道做个八成好说，要做到九成甚至更高，难度可能是指数上升的，以金钱计算投入可能都不是几百万能出什么效果的，而且得持续投入。所以更多见到的是横向的扩展，也就是在广度上进行变革，比如依托现有的成果，扩展原有的业务，以满足当前行业、用户更广泛意义的需求。能够在原有行业基础上增加几个盈利的点，虽然不足以与巨头竞争，但在本地化服务上有优势，有一定的粘性，起码可以暂度危机。还有就是另找赛道，另找赛道不一定是换行业，很有可能是在原行业中挖掘原来被人忽视的更垂直的领域需求，也有可能是重点转向在行业中的咨询、培训、代运营等形式。总之为了生存问题，行业软件都将会在一段时间内面临阵痛。不光要面对本行业的竞争，还得应对跨行业过来的竞争对手，而且有时候这种打击甚至更大。



有一个产品与技术的点想再多聊一点，就是行业软件起步早，通常都是早期的软件分发方式，销售上也更传统一些，加上行业软件通常对售前售后还需要有相对专业人士的支持，种种原因限制了企业的影响力范围。那么软件的在线化就会成为很多企业念念不忘的一个点，在线化的好处确实会很明显，不需要安装，浏览即用，各类终端设备支持容易，销售、服务、更新、防盗版也相应更容易应对。但是对于一些行业软件，计算密集，算力要求高，精度要求高，处理的内容又偏大，动辄上百兆的文件，实时要求高，如果这些处理都要返回服务器进行，这对服务端的压力很大，为了保证能满足峰值用户请求，要达到很高的稳定性，光这些开发、硬件、运维投入就不小，另一个如果存在大量的网络交互，数据量又大，对带宽要求高不说，也达不到很好的实时性。那能不能全丢给前端处理，完全用脚本实现？一个早期的脚本执行效率不高，另一个相当于将原来的软件要完全重新写一遍，这样的决定很难做。一些企业也只能退而求其次，把软件部分在线化。



现在，在线化的时机逐步成熟起来了，浏览器对于webassembly的支持给这些行业软件多了一个选择，现在能成熟支持的语言主要是C/C++和RUST，但是Go，Java这些应用广泛的语言也都在推进的路上，甚至已经可以很好的支持大多数特性。一个很典型的应用就是视频处理，比如想要浏览器支持对HEVC（也就是我们常说的H.265格式）进行解码，浏览器本身是不支持的，但是通过使用webassembly可以将ffmpeg编译进来，从而可以得到更高的解码能力。那么一些行业软件就多了一条在线化的技术选择，比如核心的、算力密集、需要尽可能在终端完成的部分就可以采用这种方式实现，而且如果原有的软件恰好使用的是可以成熟支持的语言，这个实现上就更容易，可以最大程度复用已有成果。



当然，在线化肯定谈不上能成为行业软件的生存关键，影响的因素太多了。对在线化一直抱有期望，有一个很大的原因是桌面软件的从业人员越来越少，很可能在老员工走了之后变得青黄不接，进而无法维系。



一款行业软件要有持久的生命，要面临很多的挑战，生存不易。