数字化转型网流程与架构专题将关注流程规划、流程设计、流程优化、流程风险管理、流程再造、流程自动化、流程标准化、流程监控与评估、端到端流程、微服务架构、分布式架构、云架构、数据架构、业务架构、技术架构等相关方面。
数字化转型网流程与架构专题将关注流程规划、流程设计、流程优化、流程风险管理、流程再造、流程自动化、流程标准化、流程监控与评估、端到端流程、微服务架构、分布式架构、云架构、数据架构、业务架构、技术架构等相关方面。
企业架构经常被抱怨的问题就是复杂度问题——太复杂，做不来。这方面只能说见仁见智，没法有一个统一的、令人满意的解释。毕竟，抽象讨论共性问题只是动动脑、动动嘴，笔者自己也常在一些聊天群里做这样的事情，但这不过是练练“口才”罢了。如果真要聊复杂度控制，那么脱离实际语境去讨论就属于有点“臆想”了。很多聊天，聊着聊着就没意思了，也是这个原因，抛出一个概念图来就要开始“大杀四方”，谁真知道这张图的背后到底是啥呢？
这是架构复杂度最基本的来源，架构从业务开始设计，业务复杂架构自然就复杂。比如，一个大型集团的业务架构，哪怕业务相对单一，业务自身的复杂性也不会太低，因为组织的庞杂本身就带动了业务的复杂，结构梳理起来就不会太容易，而且对流程的确认、调整都很难简单取得共识，天天都在处理的事情，也一样有说不清道不明之感。最怕的是，有些企业经常会觉得自己的业务是清楚的，但真到要较真做开发时，却怎么也定不下来。组织最奇特之处就是，可以很模糊地前进，但却给人以清晰的错觉，这可能也是流程管理一直不容易让人充分认知自己价值的一个原因吧。
小企业就会很简单吗？未必，笔者自己就是“一人企业”，但企业就是企业，无关乎是不是“一人”，签约、交付、开票、报税、发薪、宣传、设计、学习、交流等等，没有一样可以少的，只不过没必要给“一人”建立明确的流程而已。在此基础上，人数放大到一定程度之后，没有流程就是很低效的了。
但是，从流程建立开始，显式的复杂度管理也就开始了，如果企业没有类似“马斯克五步工作法”或者以前提倡的丰田精益管理之类的工作思路、管理追求的话，流程会新账压旧账，越来越乱，事情一样能办，就是低效之处很多。这时候不照镜子还勉强，一照镜子可能把自己吓一跳，吓到了之后反倒说架构复杂。
按照笔者自己的经验，人数1000人左右的企业，人手一个流程不是什么难事儿，也就是大约有1000个左右大小不一的流程或者叫活动，这一点从APQC的参考流程中也能侧面验证下，这里我们先不讨论颗粒度问题。以此为界，人数再多了之后，如果管理得当，流程数量增加未必就是正相关的；人数比这少，如果不能有意控制，流程数量下降也未必很明显，但是人数降到了哪个数量级，流程数量会出现明显的下降，笔者没有了解过，读者可以自己调查下。至少作为“一人企业”，笔者要干的事情也能凑够一个完整的价值链。
如果以此类推，非严谨论证的情况下，可能一个行业中，中等规模或者中等偏上的企业，流程复杂度已经足够高了，所以，中等规模的企业并非不需要架构能力。企业即便成长到更大规模，流程数量仍然可以有一定的控制，只是随着管理层级增加，会导致流程拉长。组织大到一定程度一般会“分裂”，也就是类似“分形”的方式产生小的“裂变体”，部门化、条线化的管理就类似这种。
如果流程控制得当，理想状态下是会有大量重复性流程出现，而不是真的增加了流程，这是“分裂”的复制结果，流程除了纵向拉长外，也会表现出横向拉长。管理得当的情况下，真实流程的增长数量应该是有限的，而很多集团企业的流程复杂实际上是标准化程度依然不高的表现。
标准化程度也左右了架构梳理结果的复杂度，很多企业觉得企业架构复杂，其实复杂的不是架构。做的过程让人觉得麻烦，正是为了消除标准化程度低导致的“杂乱”，但消除一次并非就结束了，为了保持不那么复杂，还要继续在流程优化上精进，这是热力学第二定律决定的，与架构无关。
所以从这个角度来讲，不要轻易谈降低架构复杂度这个问题。复杂度有个下限，再降低就只是在整体中转移复杂度的位置，而不是真的降低了。一个企业就是有1000个流程，如果流程数量优化不下去，还能怎么降低复杂度呢？如果在实现上就是想拼命降低，那业务人员还会觉得你做的系统是给他用的吗？
数字化转型网流程与架构专题包含哪些内容
数字化转型网流程与架构专题将关注流程规划、流程设计、流程优化、流程风险管理、流程再造、流程自动化、流程标准化、流程监控与评估、端到端流程、微服务架构、分布式架构、云架构、数据架构、业务架构、技术架构等相关方面。
