马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。如果您注册时有任何问题请联系客服QQ: 83569622 。
您需要 登录 才可以下载或查看,没有帐号?注册
x
一、个人简介
具有大局观,崇尚知识分享,赞赏为企业创造价值的环节提供更细致服务的观念;善于结构化思维,具有将商业模式与业务逻辑的“翻译”、转化与落地有独特能力;偏好创新思索与写作;在辅助决策中常有独特洞察视角。项目管理方面有一些经验,对数据库、开发语言之类基本一窍不通。事理商能洞见,人理幼稚无比,商务能力形同白痴。与人谦和为要,社会交流广泛,喜欢帮助别人。 工作简历 2010年1月- 温州市信息管理学会秘书长 2005年6月-2009年12月 东经控股集团有限公司信息部经理/运营总监/CIO 1993年7月- 2005年6月 江苏威特集团有限公司企管部经理/电子商务公司总经理/集团监事 2003年4月-2005年6月 江苏省盐城市信息化协会常务理事 二、职业生涯/人生感悟
思想旅程与工作实践
1988年在高中阶段开始接触系统论、协同论、控制论的一些观点,1992年与同学一起展开对村镇的初步研究,感觉到城镇化与城市化的差异,1998年开始实际接触网络营销工作,以该工作为基础,认识到经济社会是全息的,写了一组关于全息营销的文章,提出了“变卖为买”的概念。2001年开始企业自主的信息化项目实践工作。2005年开始继续实践,目前基于平台的内外供应链项目即将竣工投入使用。 在温州工作时间,有感于温州微观经济的实际,在经济全息与时间在经济中的独特因素,开始致力于商业生态下的时间链研究,写成有关的blog文章百余篇(http://club.youshang.com/114)。在市场环境越来越不确定的情形下,消费者和生产者的边界虽然日益模糊,但是个性需求与规模经济的搏斗俞演俞烈,不断造成有限资源的巨大浪费。初步的研究成果认为时间链可以通过对生产能力的韧性链接来兑现需求,而不需要一定通过“成品”来兑现。这些思想已经应用与当前项目。 得益于张西振先生的提携与辅导,目前正在参与和谐生产方式的研究工作。最近十年来,先后写出关于企业管理、信息化案例、前沿思想、CIO生存等文章两百多篇,散见与《企业管理》、《中国信息化》、《中国计算机用户》、《中国计算机报》、《软件世界》、《知识经济》、《软件工程师》、IT168等传统与网络媒体上。 自1998年以来,在因特网上留下痕迹颇多,自认为是一项社会工作,获得许多朋友,也在互动中学习了众多活的知识。 基于为更多企业服务的理念,2010年1月,就任温州市信息管理学会专职秘书长。
三、专家视野
3.1 信息系统之造桥与修路
一位经常往来于杭州与温州之间的朋友说,“坐在车上,不用看交通标识牌,也不用计算时间,只要留意一下上桥与下桥的感觉,就知道是不是已经到温州境内了”。为什么呢?他说,“温州桥和路之间总有2-3厘米的落差,发现有频繁的颠簸,就可以断定到温州了”。他说的是实话,不过,如果我们认为这是造桥和筑路的单位工作衔接方面没有到位所形成的,那实在是冤枉了。究其根本是温州的地质条件决定的,这是典型的丘陵地区,看上去平的地方其实早先是滩涂湿地,路基很软。造桥的时候都会打桩,筑路一般不用打桩,新的公路修好之后,原本路桥之间没有落差的,时间长了,受原始规律支配,自然也就有了落差。但就工程而言,据说现在就是筑路,也开始考虑打桩了,显然这个代价是相当大的,多说一句,即便有落差了,用几包水泥做“补丁”,或许能弥补这样的落差,有人这样建议过,后来没有什么结果,这是另外一个面上的问题了。
由于桥和路的原始地基是不一样的,我们本来希望它们能够统一成平坦路途,但是最终的结果往往还是决定于原始的地基。这个情形引起了我对信息系统的一些思考,在信息系统中,就许多应用而言,也存在着路和桥一样的情况,所不同的是,它有鲜明的时间与空间的关系,同时,系统中的“路”和“桥”还有互相转化的可能。在最近几年的实际工作中,我对此体会深刻。
民间版的路桥哲学
通常情况下,修路的成本要比修桥的成本低,现在越来越多的亦桥亦路的高架桥啊、立交桥啊另当别论。我们默认的是,路在陆地,桥则在水面之上。对于路的追求我们自然是希望保持平坦顺畅,而桥,单就交通的需要来看,我们是希望它尽量地少。局限于许多条件,很多时候不得不要修桥,修了桥之后,一方面我们会习惯的将桥当作路,比如数十公里长的杭州湾大桥,常常是默认它为海上之路的,另外一个方面,有往往希望它能被新的路替代了,历史变迁所留下的许多带桥字样的地名已经帮我们说明了这一点。
在信息系统中造桥往往是为了筑路,而道路拓宽之类又常常以造桥的方式来进行。这或许是我比较局限的个人项目体验,但是似乎存在着一定的普遍道理。
2007年,我们在为公司的供应链管理项目进行业务建模的时候,就包装物的产品化做了许多探索。图中所显示的三个阶段,分别处于2008年以前、2008-2009、2010之后。就技术条件来说,业务建模的核心工作--产品结构设计是完全可以做到网络产品化阶段的,也就是说,可以直接做成通过很少的产品属性,但是可以很精确地表达出产品在各个工序(知识生产性质的工序与物质生产性质的工序都包含)的模式。这样做起来技术负担不大,但是我们采取了“造桥”的方式,增加了技术负担,由于产品为系统的核心基础资料,它的变更将引起整体构架上的变更,项目风险显著增大,之所以如此决策,主要是考虑到业务发展的进程需要一个艰辛的语言统一过程。信息化在业务进化的不同阶段发挥不同的作用,在个别产品化阶段,就是工具,在普通产品化阶段,它其实是BPR的载体,是促进规范的一个过程,而在网络产品化阶段则是一个完全蝶化的过程,是引领业务变革的巨大引擎。
项目在2008年10月13日全部上线之后,直到2009年底2010年初这个时间里面,信息系统所起的作用与其说是业务财务一体化的多功能发力于企业管理,还不如说是为下一代的系统做测试,做demo,做基础资料。事实上从上线到2009年3月份,客户的产品已经丰富到一个惊人的数量级,这是一个结构化的将隐性的行业规则呈现的过程,信息化如果只停留在这个层面上谋求对业务的支撑,显然是相当短视的,虽然,相比以前,已经为业务带来一个崭新的改善。
当然我们不会满足于此,就这个行业的发展趋势来说,必须做到产品网络化的程度,唯有到此境地,才能实现全局急速而又稳健扩张的战略意图。
这个看上去显得很冗余的过程,其实是一个基于新业务逻辑的“中介核”-产品内在规律的认识过程。我们苏北有一句俗语叫做“两场芝麻一场打”,这个过程既满足了眼下管理升级与业务持续发展的需要,也为未来的战略实现铺了底。消耗了比较多的技术资源,目的却不是希望这个模块长期的用下去,不是被动的,而是主动的安排,这样的安排有可能为未来带来比较大的战略纵深。
深圳时代华信科技有限公司CEO万小青在2009年第二期的《软件世界》上有一篇文章《需求持续演化,技术实现如何如影相随》,我对其中的一段文字感同身受!
“一个商业软件的应用生命周期应该少于18个月”,是完全基于业务逻辑演化的频率而提出了,虽然在数字上类似于IT硬件上CPU更新的摩尔定律,但是在管理软件上为什么会是这样的一个周期?......发现在系统上线或者一个业务模式在事实上确定后,通常在第九个月进入震荡期,当然这个时间间隔在2000年之前通常为2年。所谓震荡就是业务逻辑与业务过程不够匹配,有太多的异常需要处理了。然后又进入一个相对的平稳期,但是这个时期经常有小幅度的调整,在过了一年之后到了大约第15个月的时候,一个更大规模的震荡又开始了。这个时候企业的运营系统一般都会捉襟见肘,通常会以升级的方式来平衡两者关系,事实上是打补丁,而补丁与之前的架构是没有血缘关系的,问题也就趋于严重。这个时候必须衍生出第二代的业务逻辑来,好似一些动物的蜕变,这个时候已经不是技术方面的问题。从技术构造成本来说,这个时候重新构造可能更合算。
这个可以成为软件“摩尔定律”的初步认知,恰好与我所理解的这种冗余相呼应。上线的软件或者应用,在某种意义上成了新一轮业务流程重组的驱动器,而不是应用的终结,我们都主动的将它们应用于实践。对相对成熟的应用进行主动放弃,在新的业务逻辑中继承与发扬老业务过程中的战略,从而使得企业赢得一个蜕变与进化的比较从容的时间差。
桥和路迭代互济前行
我们非常清楚,信息系统的构造不是一劳永逸的,如何实现随需而变?上面的讨论已经基本明确了一个重要的指导原则,就是需要做好“桥”与“路”的衔接,同时确定“桥”是手段,“路”是目的,在手段上我们或许要投入几倍于目的的资源,这恰是虚实之策略。。
一般来说只有上了第二级台阶,才可以上第三节台阶,虽然第三节台阶很好构造,也能迈上去,但是硬上,可能会带来“硬着陆”的痛苦,对事业有不利影响。
回顾一下我们在一期项目中,引入了虚拟产品的概念,将之前完全个性化的通过订单的参数对产品进行描述,变更为在商务确认之前进行虚拟产品构造,商务关系建立之后,直接选取虚拟产品进行少量的参数设置后即可安排供应与生产计划。这是一个重大变革,为了有效保障项目实施效果,系统设计时,有意对虚拟产品的唯一性没有作出限制,这样可以满足没有经过严格规范的虚拟产品也能正常的下订单。这个设计就是“桥”的设计,它消耗的技术资源确实比正常的“路”要多。我们通过半年多的基础资料维护工作,将98%的虚拟产品都罗列进了系统,然后在这个基础上再去做“紧箍咒”的工作,一个客户有200多种虚拟产品,通常会压缩到40-80种。这个变革过程已经设计在系统里面了,这个过程在2009年的4、5月间将全面启动,那将是全面缔造一个新的业务过程的过程。
前面提到,在“桥”的阶段,软件既是业务之应用,也是BPR的工具,这其实是作为“桥”的真正价值。通过软件自己来做BPR工作,系统本身具有BPR的功能。由于核心业务过程是基于同一流程展开的,这些局部甚至全局BPR的工作就比较简单,综合的实施成本必将显著降低。业务逻辑的延续性和业务过程进化的延续性将不是问题,组织变革的风险将得到有效控制,这恰是众多成长型企业所需要的。
3.2 用户眼中可以满足企业需求的就是好“云”
“云计算”是没有任何疑问的,其好处不言而喻,这次去日本考察,富士通已经有一个级别很高的部门在做这个事情。工具性的应用与企业管理软件的应用在国内的发育程度不一,需要分别来说。
其实我们通常用的收费、免费的电子邮件系统已经是云了,包括网站访问也是。所谓云,我想是可以这样通俗理解的,我们不用去关心硬件、软件,只要看我们的应用是否能被满足。对于企业CIO来说,大概就是不用维护机房,不用维护软件,只要代表用户提出要求,或者用户提出要求就能实现。这就是云了。好比我们可以从云里面要雾,要雨水,要雪,要冰雹,要......只要你需要,就有应对的东西与你匹配。
所以,诸如融合通信里面的视频会议,语音会议,互动IM等等,是容易“云化”的,但是企业经营管理管理的软件还难以被“云化”,目前有条件的大概就是EDI、OA之类可以做到类似融合通信的境界。生产计划、订单跟踪、财务处理、预决算等等涉及到单个组织的算法策略设置还很难通过“云”机制来完成,两边的条件还都不成熟。只有将组织变得简单了,才会有这个可能存在。
3.3 软件即服务SaaS的三重境界
软件与生俱来就是一种独特的服务。我们见到的许多商业软件,其实是省略了针对企业的细密咨询活动的服务。SaaS服务其实是将原本贴心的服务更加产品化而已,它只能在一些通用的领域得到广泛应用,涉及到企业业务的核心的服务,由软件公司提供的SaaS是无法满足的。
集成的全面的商务智能
软件与生俱来就是一种独特的服务。我们见到的许多商业软件,其实是省略了针对企业的细密咨询活动的服务。SaaS服务其实是将原本贴心的服务更加产品化而已,它只能在一些通用的领域得到广泛应用,涉及到企业业务的核心的服务,由软件公司提供的SaaS是无法满足的。
那么,未来,或者说从现在开始,软件这样的服务,到底会有哪些趋势?会呈现出什么样的特征?对软件公司而言,或者是对于用户而言,它到底有什么样的变化?
软件须通透业务逻辑
任何一个企业的诞生和发展,都缘于初始的一个朴素理念,或者说是想法、概念。要兑现这个概念,需要一个通道来帮助,这个通道就是商业模式。商业模式面对的是大量的资源与能力的集合,包括许多不可控的东西。不管什么样的商业模式都必须保证闭环的现金流出现,否则只是学术模式或社会模式。
要实现闭环的现金流,就需要一个逻辑对业务进行控制,这样就产生了业务逻辑。事实上这个环节最容易出现问题,甚至是与商业模式对立的问题,通常是短期利益与长期利益冲突。业务流程或者说是业务过程又是保证业务逻辑的,由于业务过程中通常会遇到资源、能力与需求的冲突,我们通常只顾及流程层面而经常忘记逻辑方面是否得到了进化。
随着业务的开展,这种商业模式所决定的业务逻辑被人所认识,然而这样的认识通常又是不知觉的,但是确实是非常重要的。
软件产品如果能在这个方面经受住检查,就可以说明它是通透了企业的业务逻辑,这样在实际的软件服务过程中,用户所提出的新需求,就离开不了“如来佛的手掌心”,在结构上就一定是一些有限的问题。当然这需要软件的构架支持这样的设计。
而企业的管理信息系统,从某种意义上说,就是企业的业务运营操作系统。在结构上与计算机的操作系统不同的是,它是数字信息与模拟信息并存的。软件本来是一个刚性的东西,因为它是通过一系列的规则来做事情的,但是它不能为企业发挥人们所期望的效用,而显示出它的“软”与“弱”,在本质上,是因为相对企业的业务运营实际来说,那是非常的不匹配。
这些匹配往往包含三个方面,软件是否与企业的业务逻辑匹配?软件的业务操作细节是否与企业价值活动的管理精度匹配?软件的架构是否与企业的业务发展匹配,即是否能够面向未来。这几个方面,通常是不容易同步达到的,所以大部分时候,我们会通过二次开发及升级之类的手段来满足。即便如此,在需求满足的及时性与有效性上,用户还是相当不满意的。
软件要与用户需求同呼吸
我们听过太多的软件项目失败、软件项目的烂尾、软件项目的不满意。究其根本乃是软件的服务跟不上用户的需求,任何一款软件在设计阶段一定是以可以认知的“完美”为目标的,没有一家软件公司会有意做有毛病的产品面对用户的需求。
软件太“软”,确实是因为服务太软,不是软件公司不愿意提供服务,而是经常会心有余而力不足。软件就是服务,我们所关心的是如何才能让用户得到最有效的服务?
软件是典型的管理支持产业,它受独特的商业逻辑所支配。事实上,大企业的高层管理者们已经在享受“深度支持”,这就是他们周围的各种智囊团(内部和外部的智囊团),但是,这种“支持”的成本太高了,只有少数企业的少数人才能够享用。将“深度支持”这一“贵族”产品“平民化”的唯一方法就是降低支持成本。
而降低成本的方式方法就是“基础工作统一化”—各专家型支持企业将管理方法提炼,成为一些“共享模式”、“共享模型”、“共享标准”,及“模式”、“模型”、“标准”等管理“积木”适应各自企业的搭建方式。这样,管理者就可以在“非专家”型顾问的协助下设计自己的个性化的管理系统(平台软件的完善和推广将很快让每一个企业管理者像使用个人电脑一样在信息系统平台中设计个性化的管理系统)。
在这个支持系统中,每一个“模式”、“模型”、“标准”都带有“出生证”,都能找到它发明人、改进者和其他具有使用经验的人,在需要的时候可以得到他们最专业的帮助。除了畅通的“知识供应链”之外,支持系统中还有基于新一代供应链管理软件的“物质供应链”,可以实现支持网络各成员之间的协调合作,增强信息交流的实时性,创造共享信息库,并用“站台程序”合并各网络成员企业“重复性”的职能,实现整个供应链中真正的跨企业的无缝合作。
大型的软件公司是完全有能力构造这样的系统的,我们高兴的看到,国内的一些软件公司已经开始着手通过社区以及合作伙伴论坛之类的方式提供这样的支持了。
另外也有一类公司通过开发技术平台,与用户的项目队伍协同进行开发,实际地证明了软件的生产过程就是与用户需求同呼吸的过程。即便是类似专门的服务也会以不高的成本提供,这样的服务模式,我姑且把它称呼为“万氏模式”。深圳时代华信与东经控股集团的内部供应链项目(ISCM)就是这样的模式,2006年两家公司达成意向,借助第三方的技术开发平台,深圳时代华信为东经控股集团开发100%个性化的内部供应链项目,通过努力,这个完全基于因特网的业务操作系统开始投入运行了。
这个系统的核心就是支持,用户的各个角色都可以在业务逻辑的框架内,通过截图解说的方式借助IM、电子邮件及专用远程需求提交通道进行需求提交,时代华信再将需求任务向技术力量进行分解。这样的短距离协同,最长1个小时,最短5分钟就可完成一项任务,并快速部署到用户的系统中,有效地解决了此类问题通常情况下高管理成本的服务方式。同时用户也通过这个支持型服务系统可以自助地获得各种变通的实现目的的方法,迅速地掌握使用技巧。在线应用,在线培训与在线服务都可以最便捷地得到满足。
基于一个行业商业生态系统的、围绕领袖企业核心业务的SaaS服务是未来软件服务的主要模式,也将对软件行业的发展拓展出新的空间。
转移软件服务主导权
一个软件公司对应一个单体的用户再有效的服务也是一个“简单再生产”的服务,软件业要与工业相融合,走行业信息化的路子。基于这样的普遍需求与当前的技术条件,尤其是因特网的广泛应用,未来围绕一个行业的领袖企业所操作的核心业务而展开的面向广大客户与合作伙伴的SaaS服务将大行其道!
温州是国际上罕见的产业集群集中的地方。温州的低压电器行业是在1990年前温州全行业面临灭顶之灾之后重新崛起的,成为全球的重要基地,打火机行业也经历了当年反倾销这样的灭顶之灾,赢得了生存空间,为什么没有形成电器这样的局面?现在却是更困难?其他行业又会怎么样?
电器行业是早先被动联合的,同时突破了温州老板“宁做小鸡头”的心理底线,面对共同的灾难,没有办法。对早先的电器生态系统按照领袖企业的意志进行了重组,既而通过信息系统连接,形成了现在的局面。国外巨头之所以与“大企业”合作。本质上是看好了“电器生态系统”。信息化是附着于这个生态系统的工具,是温州新生产方式诞生的摇篮。仔细观察这些在用的软件,我们会发现基于供应链管理的和单体企业管理的是可以分离的。这恰是未来温州软件业的发展重点—将单体企业的软件与供应链/供应网软件进行分离。
而打火机行业在共同面临问题之后没有这样做,现在遇到了问题。同样类型的是鞋行业,虽然有武林门的两场大火,但是行业还是没有得到类似电器行业的那样融合,没有那样的秩序,“老大”还是太多,这样该行业面对其他经济体的这个行业的竞争就显得被动。这不是一个单一的洗牌问题,而是在这个区域经济范围内,行业内的利益如何再分配的问题。
一个经济体与另外一个经济体的竞争,体现在速度、力度和厚度上,速度就是需求满足的速度要快,自然依靠许多基本工;力度是文化、品牌和技术进步,需要一个“大国”的气度来慢慢涵养,这是每天关心是否能够有饭吃的小企业无法承担的;厚度就是供应网络的纵深,温州的主要行业都有非常厚实的供应网络的纵深,但是资源被中小利益群所分化,沦为普通价格战的机器,委实可惜!
从这几个行业的情况来看,每个行业都需要一个“商业操作系统”,借以整治行业之秩序,营造更多更好的竞争力,在行业链条的每个环节上都能做到精致管理。这需要一大批有远见、有耐心的管理软件项目人员深入其中,与有远见的企业家、政治家一起来缔造。
有领袖企业打头,广大用户和供应商、合作伙伴就构成了更敏捷的商业生态系统。事实上的网络联结加上基于因特网的联结,必将诞生出一个崭新的生产方式来。这个生产方式同时是聚焦在大家共享一套系统,进行一定经济秩序的运营,SaaS的提供者将由软件公司转移到行业的领袖企业!
如果说温州存在着“第三次创业”的话,那就是在全国率先完成工业化与信息化融合的使命,将温州模式向前再推一步,演化出基于福特流水线生产方式、丰田精益生产方式之第三代的“和谐生产方式”来。
逐步增加供应网络管理的比重,与当前温州人在全球的投资、市场网络优势一起,增加对其他经济体的控制力。当然首先是增强本地各个行业的融合程度,然后逐步降低本地制造在整个经济贡献中的比重,将温州建设成为商业智慧之都,资本之都,经济体总部之都。将落后生产力彻底淘汰!
以温州为例,我们可以基于这样的假设进行进一步的假设,可以看到一个工业化与信息化在一个新的境界的融合,或许对于有兴趣的人士有一定的启发。
首先,着力行业公共服务平台建设,物色领袖企业构造类似正泰、美邦那样的信息系统,可以覆盖行业的。集中并吸纳软件资源为这些系统服务,同时开发或者改造适合单体企业应用的系统,与公共平台“主干”系统衔接。倾注政府在工业化与信息化融合方面的智力、财力资源,进行培植。这个过程是放大再分蘖的过程,是为了从供应网和单体企业抽取行业需求的需要。
其次,专注行业应用,鼓励创建各种专业的行业应用开发与集成公司,为公共服务平台、领袖企业控制的信息系统、单体企业的信息系统提供生态化支持,这样可以诞生出一大批的“插件”公司。
然后,将融合了温州产业智慧的“插件”依托领袖企业(1个行业不只是1家),对外扩张。基于对商业操作系统的设计,政府出台鼓励做应用型研发的机构按照温州版本的支持目录进行“插件”研究和开发。
最后,伴随着领袖企业对外的高强度渗透与扩张,进一步融合全国、全球的应用软件资源为这些领袖企业所代表的商业生态系统服务。
回头看一下软件就是服务的三重境界:第一重:软件体现用户逻辑;第二重:软件生产就是软件服务,与用户需求过程贴合;第三重:软件服务主导权将从软件公司转移到行业的领袖企业。
写到这里,这个假设已经超越了一般的软件就是服务的研究范畴,将软件行业与传统产业的深度融合话题以及软件企业的真切地位话题,然而这不正是一个我们都必须正面面对的服务吗?
附表 2002-2009发表的部分文章目录
| | 文章标题 | 发表时间 | 报刊名 | | 1 | 2009:“和谐生产方式”元年 | 2009-1-1 | 软件工程师 | | 2 | 构建网络模型
解决库存积压 | 2009-4-1 | 中国计算机用户 | | 3 | 集团管控:从整合资源做起 | 2009-1-1 | 信息系统工程 | | 4 | 能力延迟整合:不确定环境下的企业能力管理策略 | 2009-1-1 | 包装世界 | | 5 | 百度:如何从赢利走向持续赢利? | 2009-3-1 | 软件工程师 | | 6 | 如何减少IT服务投诉 | 2009-5-1 | 中国计算机用户 | | 7 | 谁做企业信息系统的当家人 | 2009-7-1 | 中国计算机用户 | | 8 | 社会秩序形成期的有限舆论价值 | 2009-4-1 | 软件工程师 | | 9 | SOA能否从业务领域开始实施 | 2009-9-1 | 中国计算机用户 | | 10 | IT资源如何部署? | 2009-10-1 | 中国计算机用户 | | 11 | 3G,当在3G之外 | 2009-5-1 | 软件工程师 | | 12 | 阿里软件:平台只是一个开始 | 2009-6-1 | 软件工程师 | | 13 | 性能问题错在平台软件? | 2009-12-1 | 中国计算机用户 | | 14 | “后英特尔”时代还很遥远 | 2009-7-1 | 软件工程师 | | 15 | 如何配置虚拟产品管理供应链? | 2009年14期 | 中国计算机用户 | | 16 | 要融合,不要对立 | 2009-8-1 | 软件工程师 | | 17 | 如何提升物业公司的增值服务? | 2009年16期 | 中国计算机用户 | | 18 | A4的天空是不是蓝色的? | 2009-9-1 | 软件工程师 | | 19 | 订单管产品还是库存管产品? | 2009年22期 | 中国计算机用户 | | 20 | 视频网站的商业模式有没有可能超越版权? | 2009-11-1 | 软件工程师 | | 21 | 模式之思 | 2009-12-1 | 软件工程师 | | 22 | 管理信息系统的创新革命——关系计划PK企业资源计划 | 2009-12-1 | 物流技术 | | 23 | 缩短工作时间不是有意义的创新
| 2008-6-15 | 软件工程师 | | 24 | CIO的前进方向要拐弯了 | 2008-6-2 | 中国计算机用户 | | 25 | 从“一刀准”看业务耦合
| 2008-5-26 | 中国计算机报 | | 26 | 应该签工作协议还是…… | 2008-5-26 | 中国计算机用户 | | 27 | 流程最终应向业务逻辑妥协 | 2008-5-12 | 中国计算机报 | | 28 | 构建和谐的劳资关系需要一个成长的心态
| 2008-4-15 | 软件工程师 | | 29 | 当顾问被撵走之后
| 2008-4-14 | 中国计算机报 | | 30 | 外包伙伴,该走向合资吗? | 2008-4-7 | 中国计算机用户 | | 31 | 立足基层需要,实现SOA破局 | 2008-3-23 | 信息方略 | | 32 | 如何靠IT降损增效
| 2008-3-10 | 中国计算机用户 | | 33 | 现实的CRM不相信2.0
| 2008-3-10 | 中国计算机报 | | 34 | 《中国计算机用户》读者俱乐部会员点评——IT如何解围经营困境
| 2008-1-21 | 中国计算机用户 | | 35 | 用时间来管理内部供应链
| 2008-1-14 | 中国计算机报 | | 36 | COO是CIO的第一客户 | 2008-1-7 | 中国计算机报 | | 37 | 知识生态系统
| 2007-12-10 | 中国计算机用户 | | 38 | CIO如何与CFO和谐共舞? | 2007-11-26 | 中国计算机用户 | | 39 | 信息时代办公室里不应当有个人隐私
| 2007-11-15 | 软件工程师 | | 40 | 员工个人信息是公司的重要资产 | 2007-6-15 | 软件工程师 | | 41 | 当例外有了预案 运维就掌握了主动 | 2007-6-4 | 中国计算机用户 | | 42 | 做研究式的学习
| 2007-3-30 | 软件工程师 | | 43 | 利益下的“烟雾弹” | 2007-3-8 | 信息系统工程 | | 44 | 和而不同
边破边立 | 2007-2-12 | 中国计算机用户 | | 45 | 业务模式决定项目命运
| 2007-1-30 | 中国计算机用户 | | 46 | 重要的是心态
| 2007-1-30 | 软件工程师 | | 47 | 聚焦与秩序形成系统力量
| 2006-12-8 | 信息系统工程 | | 48 | 公司也是家
| 2006-11-30 | 软件工程师 | | 49 | 发货时间 何时一目了然? | 2006-11-27 | 中国计算机用户 | | 50 | 协同是信息化的背景音乐 | 2006-11-8 | 信息系统工程 | | 51 | CIO是系统使者 | 2006-10-18 | 机械工业信息与网络 | | 52 | 在落差中实现价值
| 2006-10-18 | 软件工程师 | | 53 | 有秩序的奋斗才是速度最快、效果最好的奋斗 | 2006-9-30 | 软件工程师 | | 54 | 海归,“下蛋”前先“趴”一会
| 2006-8-30 | 软件工程师 | | 55 | 创业,不要做老板 | 2006-7-30 | 软件工程师 | | 56 | 设计渐进演化的知识结构 | 2006-7-3 | 中国计算机用户 | | 57 | 我们要谁发的证? | 2006-6-30 | 软件工程师 | | 58 | 顾问年轻拷问行业幼稚
| 2006-6-8 | 信息系统工程 | | 59 | 第三路线——做研修生 | 2006-5-30 | 软件工程师 | | 60 | 系统莫走精英路线 | 2006-5-8 | 信息系统工程 | | 61 | 乙方项目经理不必多才多艺
| 2006-2-6 | 中国计算机用户 | | 62 | 内在秩序支撑管理优化
| 2006-1-2 | 中国计算机用户 | | 63 | 信息化跟着业务走 | 2005-12-12 | 中国计算机用户 | | 64 | “管理支持产业”的商业逻辑 | 2005-11-21 | 中国计算机用户 | | 65 | 这个“烂摊子”该如何收拾? | 2005-11-7 | 中国计算机用户 | | 66 | 与其独立,不如做好眼前事 | 2005-10-10 | 中国计算机用户 | | 67 | CIO:知识经济的“催生婆” | 2005-10-3 | 中国计算机用户 | | 68 | 坚持还是放弃? | 2005-8-22 | 中国计算机用户 | | 69 | 企业经营管理系列漫谈
| 2005-8-18 | 机械工业信息与网络 | | 70 | “成功”是蒙汗药 | 2005-6-20 | 中国计算机用户 | | 71 | 小企业“草船借箭”巧做广告 | 2005-4-15 | 投资与营销 | | 72 | 需求的实现应该由谁说了算? | 2005-4-8 | IT时代周刊 | | 73 | 模式语言管理 | 2005-4-5 | 企业管理 | | 74 | 做CIO就像做媒体——传播与沟通是第一天职 | 2005-3-6 | 软件工程师 | | 75 | 信息化:渐进过程的三个为什么 | 2005-2-23 | IT时代周刊 | | 76 | 门当户对 资源匹配 | 2005-2-21 | 中国计算机用户 | | 77 | 演进的蓝图 | 2005-2-14 | 中国计算机用户 | | 78 | CIO翻身,首先要和自己闹革命——中国准CIO群体2005之嬗变分析 | 2005-1-10 | 中国计算机用户 | | 79 | 框架流程控制与支撑型流程跟进 | 2004-12-6 | 软件工程师 | | 80 | 如何避免外包可能带来的人事震荡? | 2004-11-8 | 中国计算机用户 | | 81 | “自己人”的尴尬 | 2004-11-6 | 软件工程师 | | 82 | CIO:“下海”进行中? | 2004-10-6 | 软件工程师 | | 83 | 信息化的香港视角 | 2004-9-6 | 软件工程师 | | 84 | 企业文化VS业务流程重组 | 2004-8-6 | 软件工程师 | | 85 | “头头”新上任 | 2004-7-10 | 中国中小企业 | | 86 | 信息化之前的“四化”建设 | 2004-7-6 | 软件工程师 | | 87 | 从网络营销起步的信息化 | 2004-6-30 | 知识经济 | | 88 | 信息化语言的困惑 | 2004-6-6 | 软件工程师 | | 89 | CIO阶层的“利害”分析 | 2004-5-26 | 中国国门时报 | | 90 | 信息化语言的困惑
| 2004-5-26 | 信息化建设 | | 91 | CIO:补课比创新重要 | 2004-5-6 | 软件工程师 | | 92 | 内部物流与虚拟仓库 | 2004-4-6 | 软件工程师 | | 93 | CIO是摆渡者? | 2004-4-1 | 软件世界 | | 94 | CIO:CEO的“终结者”? | 2004-3-6 | 软件工程师 | | 95 | 持谁彩练当空舞?——微软Office 2003与CIO的新选择 | 2004-2-6 | 软件工程师 | | 96 | 先项目经理,后CIO | 2003-12-6 | 软件工程师 | | 97 | 混世未必成魔王
| 2003-12-1 | 知识经济 | | 98 | 精心演绎下的范例
| 2003-11-5 | 企业管理 | | 99 | 需求决定格局 | 2003-10-1 | 知识经济 | | 100 | 做事、做人和做秀 | 2003-9-1 | 知识经济 | | 101 | 美菱E化进行时 | 2003-8-1 | 知识经济 | | 102 | 外来和尚好念经 | 2003-8-1 | 知识经济 | | 103 | 简单些 再简单些 | 2003-7-1 | 知识经济 | | 104 | 威特的信息化 | 2003-2-5 | 企业管理 | | 105 | 与软件厂商过招 | 2003-1-5 | 企业管理 | | 106 | 网络营销在疑惑中行走 | 2002-11-5 | 企业管理 | | 107 | 我搞企业信息化的五年 | 2002-7-5 | 企业管理 |
四 勋章
【勋章名称:ERP100人物勋章】、 【福娃欢欢】(奖励)
其他更多人物 请点击ERP100人物
|