NBA in Yahoo sports
NBA在美国的流程程度真的不如职棒大联盟和美式足球，从yahoo sports列表的排列顺序中就能看出，足球的地位就更别提了
小小的里程点
今天修复了来公司以来的第50个Bug，不是什么大的成就，但也算一个小小的里程点。
记录一下，BUG:421xx87 – Subject:pqeqe:omfmtqai:inv:subinv & loc values not defaulting from item txn default form
前任SAP中国副总裁：我看用友U9 PK SAP/Oracle
Copy from: http://news.csdn.net/a/20090507/211104.html
中国的ERP软件和国际一流管理软件厂商的产品到底有多大的差距？5年前我的评价是至少差20年，也就是说2004年国内的几个主流ERP产品，比如用友的U8，金蝶的K/3等，和国际一流厂商（SAP、Oracle）等比较，相差20年的水平。
5年前的差距
为什么当年，会有这样的判断呢？主要考虑的是几个因素：
1、）应用基础结构的差距：对于一个要面对各种类型企业的产品化ERP系统，它的组织构架就已经决定了它的应用覆盖面。2004年我做过一个比较， 当时的SAP R/3可实现10种以上的多组织模式，而国内产品都只能覆盖单组织应用，而且没有业务组织形态，只有行政组织形态。这个差距就决定了国内的产品很难适应有 一定业务规模的企业需求。
2、）对企业资源的数字化的差异：对于各类企业资源，其数字化的深度反映出其信息化的应用深度。同样我做过一个比较，当年SAP R/3中对会计科目的数字化是用35个字段来表述的，而当时的金蝶K/3是16个字段，这个字段的差距的背后则是ERP应用功能的差距。
3、）技术及平台的差距：支持多种操作系统、支持多种数据库、支持可扩展的开发等技术要求，是一个成功ERP系统的关键，由于技术与平台的滞后而被 淘汰出局的产品，在ERP的发展历程中比比可见。比如当年DEC的产品、王安的产品，甚至后来根植在AS400上的SSA的产品，先后都从主流市场消失。 因此5年前，国内产品的技术根基是很浅的，基本都只是寄生于微软的平台和开发技术至上，对于大型应用的支撑力度是有很大限制的。
这几个主要指标的评判，让我在2004年，得出了国内的产品和国际产品有20年的差距。
U9 PK SAP/Oracle
先不谈今天用友的产品和国际厂商的产品到底谁优谁劣，我看这场PK的本身就已经说明了问题。5年前我做这种比较的时候，没有国内的厂商提出过异议， 也没有人愿意来进行比较，但今天用友敢于把自己的U9和SAP、Oracle放到一个赛场上竞技，就已经是一个质的飞跃，我要说一句：敢比就是赢。
这2年和国内公司有了深入的接触，也看到了他们的努力，我们不妨从一个相对比较全面的角度来看看这场PK：
1、）客户群体的准确定位：
我们看到，用友公司是用一个系列的产品来对应不同的市场，它的T系列产品对应的是小型的企业，U8产品对应的是中型市场中偏下的企业，U9产品对应的是中型市场中偏上的企业，NC产品对应的是高端的市场。
再看SAP的市场对应，SAP商务套件对应的是高端市场，SAP Business All-in-One对应的是中端市场，SAP Business One对应的是小型市场。
表面上看到的是大家都有相应的产品对应不同的市场，但实际做法上，所谓的SAP Business All-in-One是源自于SAP商务套件的同一个产品，只是通过了部分的预配置来实现快速交付，其本质并不是真正面向中端市场的产品。而用友的U8和 U9则是两款完全不同的，对不同中端客户群体有准确定位的产品。所以从客户群体的准确定位而言，国内公司的更为精准。
2、）从应用效益来看：
适应性的比较：就业务处理能力而言，对于中端客户市场，目前的U9和SAP、Oracle的产品没有差距，基本都能覆盖这类客户的应用需求；就运营决策能 力而言，他们的差异也是在伯仲之间；但就战略决策能力而言，由于SAP有了Business Objects，Oracle有了hyperion之后，这个方面就强过于U9产品本身。所以整体看适应性，国外产品略占优势，U9需要有面对战略决策的 解决方案，这样才能赶上国外产品的整体解决方案的优势。
可用性的比较：无论是对用户角色的覆盖、工作内容的覆盖和易用性，U9都全面超越了国外公司的产品。SAP、Oracle，由于产品发展的时间已 经很长，其基本的思路是局限在ERP领域中，而U9则是一个全新的思路，比如集成了办公的思想、加入了企业搜索引擎、强调了个性化桌面，这些使得它的可用 性就非常人性化。所以在可用性上，U9产品应当占据优势。
可扩展性的比较：就技术扩展性而言，U9产品有了一个非常大的变化，就是全面基于SOA架构体系，因此它的技术可扩展性有了很大的提升；而就应用 可扩展性而言，各种类型的多组织模型的出现，使得U9在这方面已经有了和SAP、Oracle一样的结构基础。这两个变化，可以说是国内产品的一个质的飞 跃，虽然从整体判断国外产品还是具备一定的优势，但U9已经突破了长期阻碍国内产品成长的屏障，具备了快速赶上甚至超越的能力。
总拥有成本的比较：无论是产品的购置成本、实施成本、用户的应用成本和系统的运行成本，U9继续保持着国内产品的本地成本优势，这个本地成本优势并不是简单的低价格，而主要是运行维护成本适应国内企业的实际情况。
综上所述，应该说整体的应用效益，U9和国外产品不相上下，目前在可用性和总拥有成本上强于国外厂商，在适应性上稍逊于国际产品，在可扩展性上还是 弱于国际厂商。但由于U9的基础架构无论在应用上还是技术上，都已经打下了良好的基础。相信随着一定时间的积累，再加上用友强大的中国企业用户基础，U9 会很快在后面两点上赶上并超越国际厂商。
3、）从客户的应用成功看：
要把U9和SAP、Oracle真正PK一下，那就必须到实际的客户当中去，目前很难下一个结论，毕竟U9的产品刚刚进入市场，而SAP、Oracle已经在中国经营了10多年，但偶然做了一个客户调研，得到这样一组数据：
公 司A，SAP的成功客户，1998年购置SAP的R/3系统（当年企业的年营业额是5亿6千万，员工900人），1999年系统上线，2002年系统进入 稳定运行，2004年升级到SAP商务套件（当年的企业年营业额是18亿4千万，员工1500人），实施并使用了SAP的主要ERP应用功能（FI/CO /MM/PP/SD），其6年的总投资（软件、实施服务、维护、IT人员费用）估算为1600万。目前应用效果非常良好，企业的全面经营管理已经完全依托 于建立起来的信息系统之上。
公司B，用友的成功客户，2002年公司创建并购置用友U8财务模块，2005年扩展购置用友的U8进销存模块，2007年扩展购置U8的生产制造 模块，2008年升级至U9，其间企业还购置了OA、CAD等系统，到2008年信息系统支撑的企业营业规模是20亿，人员1200人，其6年信息化的总 投资（软件、实施服务、维护、IT人员费用）估算为955万。目前应用效果非常良好，企业的全面经营管理已经完全依托于建立起来的信息系统之上。
从这两个案例来看，不管是国内产品，还是国外产品，都有非常成功的应用，而应用的成功与否，除了厂商的因素以外，更大的因素是来自于用户本身。这就 是成功的机会成本问题，用国外产品虽然产品相对稳定，但一次投入需要逐步消化，其机会成本相对较高，而国内产品这样的逐步投入，渐进完善的模式，机会成本 被分摊，相对成功付出的代价要小很多。
今天用友U9和SAP、Oracle同台竞技，可能暂时还不会出现全胜的局面，但毕竟是走到了同一个竞技场上，我觉得对中国客户而言，这是一个绝对的好消息。在目前中国企业全面转型升级的时代，敢比就已经是一个赢的开场。
作者介绍：黄骁俭先生现任上海乐勤企业管理咨询公司创始人、合伙人。 曾任全球最大企业管理软件供应商SAP公司的前任大中国区副总裁，金蝶公司副总裁。
[转]甲骨文CEO：不出售Sun硬件业务 继续对SPARC芯片投资
北京时间5月8日早间消息，据国外媒体报道，甲骨文CEO拉里埃里森(Larry Ellison)表示，他不会出售Sun的硬件业务，驳斥了其收购Sun只是看中了软件业务的传言。
甲骨文上个月斥资逾70亿美元收购Sun在硅谷引起了轩然大波。埃里森在接受电子邮件采访时说，我们不会退出硬件业务。与只设计软件的公司比，同时设计软、硬件的公司能够开发出更好的系统，这就是苹果iPhone(手机上网)的表现远远优于使用微软软件的手机的原因。
埃里森的这番评论驳斥了部分分析师有关甲骨文可能出售Sun硬件业务，而只保留软件业务的推测。最近数年，甲骨文稳定增长的利润率引起了华尔街 关注，分析师认为，甲骨文收购Sun是在玩火。Sun第一财季亏损了20亿美元。埃里森没有回答如果振兴Sun服务器业务计划受阻将何去何从的问题。
市场研究公司Pund-IT Research分析师查尔斯金(Charles King)表示，埃里森的评论无疑给因前景不明朗而不愿意购买Sun硬件产品的企业客户吃了一颗定心丸，有传言称甲骨文将分块拍卖Sun的硬件业务，许多客户都考虑采购其他厂商的产品。
继续对SPARC芯片投资
埃里森表示，计划增加对SPARC处理器的投资。SPARC服务器的最大买主是大型企业和政府机构。他认为，通过整合甲骨文的软件、SPARC 服务器，甲骨文能够提供性能更高的系统。甲骨文过去曾与包括惠普在内的厂商合作，联合提供软、硬件产品。收购Sun后，我们能够像IBM等大型厂商那样更 好地协调软、硬件功能。甲骨文计划与富士通合作，为SPARC处理器增添新功能，提高在Sun服务器上运行甲骨文数据库的性能，这将提高Sun硬件产品的 竞争力。
埃里森还表示，他有意保留Sun的数据存储业务和磁带备份业务部门，在过去相当长的一段时间内，Sun销售SPARC-Solaris服务器取得了极大成功。如今，在甲骨文软件的帮助下，Sun将再现辉煌。
市场研究公司ITIC分析师劳拉迪迪奥(Laura DiDio)表示，甲骨文能够帮助Sun重新成为世界上最受尊敬的高科技公司之一，Sun在过去30年中投资数十亿美元开发了优秀的硬件技术，有天才的工程师，但其营销工作跟不上，而埃里森恰恰是一位营销大师。
[转]Sun公司发布2009财年第三季度财报
Sun Microsystems公司(NASDAQ: JAVA) 今天发布了截止到2009年3月29日的公司2009财年第三财季的财务报告。
2009财年第三财季的营收额为26.14亿美元，而2008财年第三财季的营收额为32.66亿美元，2009财年第二财季的营收额为32.20亿美 元。该季度的总毛利为营收额的42.7%，与2008财年第三季度相比，减少了2.2个百分点，与2009财年第二季度相比，增加了0.8个百分点。
按照美国通用会计准则(GAAP)计算，2009财年第三财季的净亏损为2.01亿美元，稀释后每股净亏损27美分，而2008财年第三财季的净亏损为 3,400万美元，每股净亏损4美分。2009财年第二财季的净亏损为2.09亿美元，每股净亏损28美分。2009财年第三财季的GAAP净亏损已将主 要与2008年11月宣布的重组相关的4,600万美元的费用计算在内。
按非GAPP计算，2009财年第三季度的净亏损为5,200 万美元，稀释后每股净亏损7美分。2008财年第三季度的非GAPP净收益为1.32亿美元，每股净收益17美分。2009财年第二季度的非GAPP净收 益为1.14亿美元，每股净收益15美分。非GAAP每股净收益不包括：已投入的研发费用、与收购有关无形资产摊销、股权奖励、重组费用、固定资产折旧、 产权投资损益及非GAPP调整后的税收影响。
2009财年第三财季结束时，Sun公司现金和有价债券结余为29.9亿美元，由经营所得的现金流量为1.78亿美元――这是公司2009财年中连续3个季度实现经营业务现金流量盈利，此前已连续19个年度实现经营业务现金流量的盈利。
2009财年第三财季的亮点：
·各类软件、开放存储、基于Solaris的SPARC CMT服务器和X64服务器等主要产品的营业收入取得了近4%的年增长：
· 在2009财年第三财季，这些主要产品的营业收入占总收入的40%，而2008年第三财季该比例为30%。
· 各类软件收入的年增长为28%。
· 开放存储营收的年增长为63%。
· 基于Solaris的SPARC CMT服务器营收的年增长为3%。
·研发支出和行政管理费用与上财年相比减少了15%。
Oracle收购公司的列表 (List of acquisitions by Oracle)
”Oracle收购公司的列表“（List of acquisitions by Oracle）已经成为Wiki的一个词条。这个词条列出了05年至今Oracle收购的几家重要的公司。Sun赫然其中。
其实在Oracle官网上就有对所有收购公司的一个汇总分类，参见Strategic Acquisitions
《List of acquisitions by Oracle》
This is a listing of Oracle Corporation’s corporate acquisitions, including acquisitions of both companies and individual products.Oracle’s version is here, but does not include value of the acquisition.
This list is incomplete; you can help by expanding it.
换成wlsy制作的SimpleG Theme
无意间看到了wlsy 制作的SimpleG Theme，那个喜欢，立即把我之前用的Keso Theme无情的给换掉了…
SimpleG相对于我之前的Keso的Theme略显复杂些，但是从字体感觉和色彩搭配上更好些
这里也感谢下wlsy:)
金蝶终于搬家了
金蝶终于搬家了，不容易啊
转贴几张同事的PP
BBS式的Bug系统
无意中一睹了Redhat的Bug系统的芳容，催生了我写这篇文章的想法。
我所在的公司Oracle的Bug系统和Redhat的Bug系统非常相似（莫非国外大公司的BUG系统都是这样的?），所以对这样的Bug系统有着切身的体会，作为开人人员，绝大多数的时候我们每天打交道最多的其实也就是Bug系统，所以早就有想法写一篇关于Bug系统的文章。
从界面上，我们能够看到Redhat的bug系统主要由两大块组成:
Bug Header，主要用于说明了这个Bug的标题，优先级，所发生的模块，bug的状态，当前处理人…
Bug Body，最开始的地方，QA或者客户先把Bug的内容作一描述，以及相关数据文件的路径…,然后开发人员分析，索要更多信息，关闭bug
从客户或者QA的角度，你能够很好的跟踪一个bug所处的状态，开发是否在修改bug，修改bug的进度，这个进度可以是非常详尽工作状态，比如开发人员有没有发现这个bug的Root cause，是否需要从客户环境获取更多的信息。这样的Bug系统是一个宝贵的资料库，可以供以后的开发人员参考，你的一份付出，可能可以很好的帮助到后来遇到类似BUG的开发人员，以后开发人员遇到了类似的问题，就可以参考你现在的修改方式，这样可以让后来人快速的站在前人的肩膀上。
这样的Bug系统还有的好处就是，当一个还没有修复完的Bug转给了另外一个开发人员，那个新接收的开发不是从零开始来的，他可以根据之前开发的一些文字获取更多的信息，很快的就可以站在“巨人”的肩膀上。
当你第一次看到这样的Bug系统，你会感觉它就是一个加强版的BBS。客户或者QA作为帖子的发起人，然后由开发人员进行回帖，在回帖的过程中，其他的开发人员也可以参与进来。开发人员可能一下没有明白发帖者的目的或者意思，可以要求发帖者（客户或者QA）提供更多的线索。开发人员在修复的过程中可以不断更新这个“帖子”，让客户或者QA知道你“在”做着，以及相应的进度。
现在国内很多软件公司的Bug系统更多的是注重Bug的统计，你未改bug是哪些，已改bug有多少…而对于你所每个bug的细节很少有关注。你打开一个未改的Bug，只有QA寥寥的一些描述和图片，如若不清楚，只能通过邮件或者IM的方式和QA交流，殊不知开发所问的问题，和QA的答复都是相当有价值的（对于后来人来说）。开发人员修复了一个bug就是一个，这个bug完全没有任何“影响力”，那么开发人员的工作所体现的价值也大打折扣。项目经理若想知道你某一个bug进度，只能通过询问这个开发人员才能获知，无形中也增加了沟通成本。
走出软件作坊-随笔一
最近好忙，都在拼了命的赶进度，很少有时间写写日志。
尽管很忙，还是每天抽出点时间(基本都是睡觉前用手机看的)，把阿朱的《走出软件作坊》看完了，收获颇多，等果断时间有空了，把读书心得总结下。
《走出软件作坊》所描述的行业就是企业应用这个行当，算下来我也在这个行当混了4年了，所以阿朱笔下很多的情景，还真的有种似曾相识的感觉。
我也会在以后的文章里对这本书做一些总结。
上周宜家定的桌子和柜子到货了，新桌子好爽，宽敞，台式机笔记本都放上去也不觉得拥挤。买这张桌子，主要是看到网络达人Keso上传的图片后，顿生买意。
