OA | 项目 | 合同 | 知识 | 档案 | CRM | KM | ERP |  设备 |  专题       
伟创首页 易企管 定制软件 解决方案 经典案例 行业资讯
关于我们  |  联系我们  | 400-0906-395

伟创软件:办公软件专家

+ 企业信息化咨询顾问      + 办公软件集成方案      + 企业信息化解决方案     
+ 数据集成及安全方案      + 数据挖掘解决方案      + 移动办公及云办公     
当前位置: 伟创软件 -> 软件服务 -> 传统企业之殇

办公自动化系统

互联网大佬们的学习故事

伟创软件 -> 办公自动化系统
这些年来,随着互联网创业热潮的兴起,很多90后甚至00后出现了各式各样的天才少年,创业头条中各种XX天才辍学创业,年收入过百万,已获N论融资等等。似乎,每一个天才,想要在这个因为互联网产生巨大商业变革的时代中拔得头筹,除了快,就是快。快到书有时候都可以不读,但创业必须先开始。比尔盖茨,不就是大学没毕业就辍学创业,然后一鸣惊人,创建了举世闻名的微软吗?所以大学读书无用论获得了很多人认同。 ..

什么是大数据真正的价值?

伟创软件 -> 办公自动化系统
现在,大数据对于物体如同知识对于人脑一样,如果物体利用大数据的核心技术 (机器学习,自然语言处理,数学建模,人机交互,语音识别,大数据分析、数据可视化) 可以加工数据到信息再到智慧,去做支撑,那么随着数据存的越多,处理的越好,利用的越有效,物体拥有的智能就如同人一样拥有智慧。因此,大数据的出现为人类生产智能的商品提供了一种强大的能力,我们发现大数据+物体=智能;..

真正的互联网是什么?

伟创软件 -> 办公自动化系统
 何为互联网?怎么产生了互联网?它从哪里来?又会到哪里去?..


更多文章..

传统企业之殇

作者:佚名  来源:网络
导语: "设计系统的组织,最终产生的设计等同于组织之内、之间的沟通结构。"--Conway'sLaw.

设计系统的组织,最终产生的设计等同于组织之内、之间的沟通结构。"--Conway'sLaw.


传统企业之殇

    运维之痛1:人肉vs平台

    人肉不是传统运维的当下过失,是过去的延续。在早期,运维的很多能力建立在少量的高可用硬件对象之上,平台化的需求很弱。另外,闭源的软件生态,给平台化的建设增加难度,而这些历史债务,并不是一下就能丢下的。留给传统企业的时间并不是那么充足,开放平台和业务的互联网化带来的冲击是非常大的,时间非常的短。这是一个多维冲击能力,从思维、技术、能力等多个维度。

    不过很开心的是,传统企业运维人对运维平台拥抱非常强烈,从运维自身能力自动化到全流程的持续交付自动化。我也经过和传统企业的IT部门深入广泛接触,大家对运维自动化作为突破口非常认可,更愿意以此为原点,单点突破,再全面覆盖。

    运维之痛2:流程vs创新

    很多人会告诉我,在传统企业中没办法,我们必须通过流程来驱动各个组织角色,确保协同工作。真的如此么?我们在腾讯维护那么多产品线,没有流程怎么做到的?然后真的会混乱不堪么?我和我之前的运维团队来说,如果你不能保持一个对外的简单清晰运维界面,那就是我们工作的失职。

    流程是我们找不到解决方案的时候,添加的累赘!很荣幸,我了解的传统企业中,给我上了一趟生动的流程课,此处和大家分享一下。

    场景1:服务上线申请

    我们都知道根据TOGAF框架,企业中分业务架构、数据架构、技术架构和基础架构中,你仔细去看看定义,非常的完美。但我觉得这种集中式的垂直划分,就是问题所在,谁能做到全局的架构设计,特别是面向应用端的系统设计。这个时候问题来了,一个研发有个业务上线,首先找到了基础架构组要服务资源,基础架构组和研发说,你要和业务、数据架构组先评估一下数据需要,和技术架构评估一下技术架构要求才能确定基础的资源需求。真要如此复杂么?其实就是一个业务上线而已,我们评估了那么多的业务容量,就那么几个指标而已,访问量、读写、热点集中度、数据量大小等等,基本上能评估一个业务完整资源需求。这是一个绕圈式的流程设计。

    场景2:附加角色

    环境搭建太痛苦了,增加一个环境管理组吧;各部门的目标不一致,KPI无法协调,成立一个目标管理组吧;流程没法协调,成立一个流程组吧;质量不行,成立一个质量管理组吧。我觉得这些都是附加角色,所谓的附加角色,就是在没有找到实质解决方案的情况下,不断的添加一些check角色来改进现状。真的改进了么?没有,附加角色只会是增加了事务的复杂度和后续的执行难度。

    那怎么办?这类问题要不断的问自己,为什么环境搭建痛苦?环境太多,太复杂了,为什么复杂?每个业务不一样?为什么不一样?是因为架构不统一,为什么不统一?....问题的改进,其实就是工具和最佳实践的不断组合迭代。

    运维之痛3:责任分离vs持续改进

    没有比责任分离更糟糕的事情了。在一个问题产生的时候,大家首先不是想着如何寻求更好的解决方案,而是在找这个问题应该由哪个团队的责任。责任分离可以说是过度流程化的结果,流程设计者们很多都在精心设计责任应该由谁来背。当责任被清晰的界定之后,而后的解决方案也只能落到该团队上了,自然而然,思维就局限了。

    其实应该换个视角,当业务的质量出问题了,持续交付这个链条上的所有人都有责任,而基于责任的分析范围应该更广泛一些,需要思维上的突破。我们总是怪测试不够充分,你给到足够的时间给测试了么?你让测试早期参与了么?你建立了稳定的技术框架,让自动化测试更好的覆盖了么?怪运维的环境部署有问题,你有降低运维部署的复杂度么?怪运维定位问题慢,你有把运维定位故障的复杂度降低么,消除了菜鸟和专家的区别么?反之亦然。

    更糟糕的是,当问题变得越来越严重的时候,还在想着流程设计得不够完美。

    运维之痛4:组织设计

    "设计系统的组织,最终产生的设计等同于组织之内、之间的沟通结构。"--Conway'sLaw.

    不得不说,传统的职能式的IT组织架构越来越不能满足互联网化的业务需要了。基于持续交付打造的全链条整合链条打破的就是职能边界,提供的就是面向产品化的服务能力。如果组织不能给新产品上线和老产品快速迭代提供足够的能力支撑,那么这个组织一定是冗余设计的。架构组提供的架构能力只能是一个意向参考,没有真正的落地实现,这个架构组就是冗余的;流程组提供的流程能力是减慢了交付速度,这个流程组就应该去思考是否把流程让位于更优的技术实现。

    很容易观察到的一个效果,复杂的组织设计,最终让设计出来的软件复杂,导致问题重重,随后便不断的增加附加角色,让软件的交付过程主次不分。其实附加角色增加的检查点并不能起到服务改善的作用,“越早发现缺陷,越早修复成本越低”这个准则需要深刻体会,check机制都是事后的机制,是人肉机制,而自动化的机制必须早期介入。

    糟糕的情况,组织设计完全面向问题,而非面向用户。谁能代替用户来对IT组织的考核?没有。但我们的方式恰恰相反,认为考核组就可以,针对每个小组,设计了一些指标。说实话考核组离一线现场太远了,数据的是非判断准则都很难建立。

    运维之痛5:架构设计

    架构设计的问题是一直是核心的技术问题所在。架构设计问题体现在很多方面:

    1、不能建立统一的架构标准

    架构师在传统企业中是普遍的存在,而架构规范恰恰不是普遍的存在。很多时候都让位于业务的复杂需求,认为技术架构标准可以放低。技术架构标准绝不是架构师的呼声,应该是产品线的统一技术要求。合理的技术架构,会大大提升后续的产品推出速度和演进速度。

    2、从代码依赖到二进制依赖到服务依赖

    很多传统企业的大型软件之间采用的还是代码依赖,当一个组件发生变化的时候,这个时候需要整个系统的全量更新。久而久之,更新的代码影响哪些外部系统,都不知道。这是深度耦合,给后续的测试和运维都带来了很大的难度。到服务依赖,才能真正的实现架构自治。


专业定制软件/服务
OA协同办公系统 ERP企业资源计划 CRM客户管理系统 KM知识管理系统 项目管理系统
合同管理系统 HR人力管理系统 进销存管理系统 流程管理系统 档案管理系统
 
关键词: OA  ERP  CRM  KM  HR  合同  ERP  流程  档案  设备  考勤  项目  协同  知识  移动  OA概念  工会  施工  车辆  行政  资产  供应商  物业  工程  工时  不动产  国有资产  自建房  宅基地  公租房  国有不动产 
 
热线电话:400-0906-395  伟创软件-办公软件专家 All Rights Reserved. 资讯专题  行业专题  伟创软件  京ICP备17005839号 
项目 | 设备 | 知识 | 合同 | 档案 | 物业 | 工程 | OA |