这个故事讲的是一家拥有百年历史的制造业大厂的信息化转型过程当中的波折。这家企业拥有超过三万名员工,它是某行业的领先品牌,可是在信息化程度上却很是古老。 html
有许多人说,国企的项目都是坑,至关一部分项目都是为了骗经费而忽悠人的,换一拨管理层,基本上就得换一拨项目,油水全被领导捞走了。我很遗憾,没能经历这些事情。这个项目实打实都是作出来给基层用的项目,也确实得到了各方较高的满意度。 网络
以中台为政治正确的互联网开发者们会说,这个项目从商业层面和技术上来讲彷佛毫无价值,首先它不是互联网产品,其次它没什么技术含量,什么大数据,云计算,容器,微服务,无服务,它都不须要,这甚至有点像咱们身边许多人十年前就作过的项目,技术上平淡无奇,看起来毫无挑战。 架构
显然并不是如此,每一个项目存在都有价值。做为过程当中的亲历者,我但愿经过总结这个项目过程当中存在的不足,引发思考和引起讨论。尤为是随着时代的进步,像这样信息化转型的传统制造业企业,或许愈来愈罕见,这样的项目看起来很是独特,但也是软件项目中的一个典型,对于将来从事行业互联网开发的软件从业人员来讲,也许能带来一些思考。 微服务
2015年开始,制造业企业开始流行起一种新的趋势:工业4.0,在这个大背景下,国内则提出了中国制造2025的计划,旨在经过几年努力,实现中国制造业的智能化水平在上一个台阶。 学习
该大型国企做为该某领域的领先品牌,其生产的产品远销国内外,也是军民融合的典型表明,可是在过去的发展过程当中,因为产品自己比较特殊,许多关键步骤仍然是采用手工完成,没法彻底实现自动化替代,包括检验管理体系也一样创建在一大堆纸质表单的基础上完成。集团管理层看到了中国制造2025带来的巨大机遇,也想奋斗一波,但要作的事情实在是太多了。 大数据
康威定律说,一个组织的软件架构设计,其实是组织管理形式的体现。在9012年的今天,为了维持这样一套以纸质表单为核心的检验管理体系,须要维持庞大的管理体系,带来了巨大的管理成本,对于组织来讲自己成为了一种巨大的负担。更况且这种管理形式,问题实在是太多了。 云计算
1,须要花费大量的时间和精力来维持现有组织,哪怕是非关键岗位的离职,均可能影响一些流程的开展。(纸质资料的交接,其实跟口口相传没什么区别)。 spa
2,过程资料存储困难,为了存储资料,更是须要专门安排档案室和档案保管员,一旦出现产品质量问题,须要进行问题追溯时,要从档案中检索问题要花许多时间。 架构设计
3,一旦发生灾害或事故,例如火灾洪灾,就意味着过程资料将成为废纸,产品的关键过程信息将没法寻觅。 设计
在互联网技术飞速发展、实体经济受到巨大冲击的今天,原有管理模式,过于臃肿,已经没法适应组织发展的须要。行业愈来愈不景气,企业的管理成本居高不下,负担愈来愈重,每一年裁人裁了许多人,却没能从管理效能上带来多大的提升,所以提高企业的信息化管理水平其实势在必行。
可是若是要实现一步到位,直接构建基于工业4.0的智能制造新体系,在这个行业都不太现实,毕竟许多产品都是属于定制生产、小批次制造,部署全套自动化制造生产线成本很是高,事实上新生产线也在建设,可是一直没有投产,老的生产线也得维持好,这样才能持续创造价值。作好眼前能作的,实现检验管理的信息化(无纸化),而后再逐步实现制造业的智能化,只有实现了这一小步,才有将来的无限可能。
以前提到中国制造2025的大背景,还有一个小背景。企业内部企业的中高层广泛都是八十年代末毕业拥有更高学历的管理层,不乏清北的高才生。他们那些大学同窗正是这一波大时代的受益者之一,有许多同窗都借助于企业的腾飞实现了我的价值,可是留在这家国企的高管们,却看着企业愈来愈差,也想有所做为,却感受一个拳头打在了棉花上,他们的压力很大。
然而,你们都清楚,传统国企的体质僵化,不少时候看起来两个字所谓“变革”,实际上却有点像个好梦而已,就拿“信息化”系统建设来讲吧,信息化对于国企来讲并不是第一次提起,许多国企的老员工,乃至管理层其实已经经历了过去十年信息化失败之苦,许多信息化系统在领导们的支持下,看似搞得轰轰烈烈,热热闹闹,可是最终都难逃被抛弃的下场,而每一个信息化项目的失败,都会让好几位负责对应信息管理工做的牵头人背锅,并最终从公司离开。
在IT从业人员看来或许很简单的信息化建设,历来没那么顺顺利利,极有可能会因为基层的抗拒最终失败,并给信息化建设的参与者带来职业生涯上的污点。
因而在国企把信息化提上议程以后,得到了两种不一样的声音。很戏剧性的,不懂信息化的业务部门是信息化的支持者,他们说这个事情必定要搞,砸锅卖铁都要上,再难也要上。另一种负责信息化工做的信息中心的负责人对信息化的态度很明显,要我支持,没问题,我能够把网络作好,可是要我参与软件的研发过程,恕我无能为力。
所以最终牵头组织这个过程资料信息化的,是平时对这一块需求最大的检验管理部门。在他们的推进下,项目正式提上了议程。
这是个涉及面很是普遍的项目集,包括了三个项目,分别是面向民用领域单一事业部的A项目,面向融合领域的B项目,以及面向整个集团全方向的C项目。事实上集团曾经购买过现成的产品,可是都没能用起来,因此这个项目集最终是以定制开发的形式承包出来。
A项目做为最早立项的项目,万事开头难,承受了巨大的压力,许多人在等着看一出好戏。
A项目的负责人W部长今年三十八岁,在此以前他一直是从事检验管理出身,对产品检验有本身明确的要求,他奠基了整个项目的基调。没有设定特别宏大的目标,不是作一个通用的大系统,就作一个简单实用的系统,可以给基层带来方便,为管理层带来便利就够了。
项目的早期,承建单位曾经试图引入新技术和更加友好的用户体验,可是w部长却不这么认为,他说在这样的老国企,不必用新技术,一切以知足可用性为目标,操做越简单越好。因而最终承建方设计了一个基于cs的数据采集系统和基于bs的管理系统。不只功能 尽量的简单,并且连流程都能省就省,尽可能让参与者减小学习成本。
这个设计简单实用的系统,刚好知足了敏捷项目所要达到的构建简单项目、实现快速迭代小步快走的管理目标。驻场开发期间,及时发现问题和解决问题,让软件获得了很是充分应用,得到了甲方的高度评价。
并且若是说早期项目的应用的推动须要靠组织的强势推进,到了后期就使人欣慰了,因为这个系统无需特别复杂的操做流程就能完成资料的录入,提交和汇总,基层岗位的工做人员只要会用计算机、简单培训就能迅速上手,无形中为项目的快速铺开奠基了良好的基础。并且承建方与甲方的基层人员之间沟通融洽,有问题及时反馈,及时处理,为项目推动带来了很是不错的效果。
在项目运转正常一年以后,主导项目工做的部长调任了,新接手的负责人是曾经不太看好这个系统的车间主任,他也被基层工做人员带动,成为了这个项目的拥趸。
借着A项目成功的东风,立刻启动了B项目。
前面提到了,B项目是面向融合产业的,所以对这个项目的要求也相对而言更高。
当这个项目完成立项后,B项目建设方的组织架构也发生了比较大的变动,首先是以前推进A项目的集团公司大领导因为工龄届满,已经退休,而集团的整个管理层都相继发生了变化,包括推进项目立项的一位高级工程师也从公司离职,意味着项目早期干系人已经彻底换了。
组织架构调整实际上是为了给年轻人机会。调整后,B项目负责整个项目的,都是87后的年轻人。
这群年轻人们,相对于A项目的负责人来讲,对信息化有了更加深刻的认识。事实上而言,A项目建设,其实不过是一个相似于协同办公的一个模块,他们认为这个项目没什么技术含量,甚至有点low。他们常常出去考察学习,对用户体验和功能应用都有不少想法,他们渴望真正打造一个可以真正打造一个符合企业将来发展目标的信息化一体化平台。
这些想法再跟现有政策、以及组织架构混合在一块儿发酵,最终变成了一个无比巨大的项目,用专业术语来讲,就是一个“大泥球”系统。
在项目立项之初,合同上原始需求其实只有19个条目,并且为了让这些内容容易落地,前期的推进者甚至尽量的减小流程的复杂度,可是等合同签定后、组织结构调整完,新的干系人们在原合同的基础上,对范围进行了大幅修改。最终等需求调研落地,变成的是一个基本上涵盖了公司大部分审批事项、涉及几十个流程,涉及全公司数百人、超过十几个小系统的大项目。
为了完成这个项目,双方投入了最少20我的,超过十人的研发团队驻场开发了超过半年时间,也没折腾出几个让甲方满意的东西。建设单位现场条件恶劣、涉及流程复杂、涉及特殊的管理机制,要开发的功能点特别多,不断的完善,不断的修改,整个项目研发前先后后折腾了至少一年时间以后,才经过直接负责人的承认,可是给领导汇报时,却根本不可用,得推翻重作。
项目到今年项目依然没有上线,这离合同交付日期已经超过两年了,显然能够称之为“失败项目”了。
承建方虽然早期意识到了项目风险,可是建设方过于强势,没法拒绝;建设方贪多求快,忽略了组织自己的复杂性、低估了软件研发的工做量以及软件实施的难度,最终双方都竹篮打水一场空。
C项目是在B项目完成了到一半时启动的新项目,其目标是将A项目成功的经验,推广到全集团。(不包括B项目的事业部)。
C项目的实施异常顺利,合同期一年,实际上只花了8个月就把项目作完了。
当我年轻时曾经向其余拥有丰富经验的项目经理请教什么样的项目才是成功项目时,他们说:
“刚恰好”:刚恰好知足客户的需求,就是一个不错的项目。
一个充满智慧的回答。不过“刚恰好”其实很难把握这个度,我以为必定是功能简单、实用便可。
在这个故事中,那个最简单实用,几乎没有什么技术含量的项目在组织中得到了很大的成功,而一开始就打算作成全流程信息化的系统,最终却一败涂地。
这刚好就像咱们常常见到的项目,简单纯粹的产品才能最早站稳脚跟、得到不错的用户反响,那些一味画饼的PPT项目,都是忽悠人,几乎没几个成功了。
除此以外,每个软件行业从业者,越爱钻研技术,越容易陷入技术的迷思,总觉得靠技术能改变世界,仿佛一个项目没用上什么新技术就容易就没法体现出本身的价值来。然而一个组织的技术体系,必须依托组织的实际组织架构而存在。再优秀超前的技术,脱离了土壤都是空中楼阁,永远没有最优秀的技术,能真正为组织带来价值的技术,才是最合适的技术。
原文出处:https://www.cnblogs.com/xiyuanMore/p/11651870.html