2008年新的劳动合同法开始实施。新劳动法的条款里对劳务派遣的限制增多，尤其是连带责任的提出，更是提高了劳务派遣的成本负担。因此，用人单位为了规避这样的风险，更加关注服务外包，来替代劳务派遣。新的劳动法将加速中国人力资源外包的流程，将会有更多的企业采用Contracted Service，这种现象在国外已经普遍，如《世界是平的》所描述的场景。
对外包公司而言，新劳动合同法的实施意味着行业的新一轮洗牌。 外包需要一个规范的市场，需要一个公平的交易平台，而新劳动法的规范恰恰提供了一个竞争有序的发展空间，优秀的外包公司将获得更多的机遇。
对企业而言，用好外包公司却不是一件简单的事情，特别是对软件外包等不同于简单劳动力密集型的工作。据我了解，国内银行和外资银行都赶在2008 年1月1 日的大限之前，把一批从事简单、重复劳动的服务人员转成了外包关系；而国内的一些所谓高科技企业却相反地把一批从事软件开发的PT（Part Time）员工予以转正，或者在08年的Q1都增加了技术开发职位的head count。
高层管理人员肯定清楚在《新劳动法》实施后正式员工的用人成本大大增加，那这么做的苦衷就是：企业自身的管理水平和管理能力不过硬，工作无法“包出去”。而且，工作要能够“包出去”，还要求企业的系统（软件、硬件）的架构具有开放性openess、可适应性flexibility、模块性 modularity。“包不出去”，说明企业在技术架构和管理水平上遇到了双重瓶颈。
一、管理瓶颈
IBM、SAP看到了机会，向企业推销自己的研发项目管理解决方案和工具，或者是人力资源关系全生命周期管理软件等。
另一方面，除了上述的重量级解决方案，一些轻量级的、敏捷的软件开发过程也大行其道。
二、技术瓶颈
整合是软件行业经久不衰的一个主题。
很多公司的工作之所以“包不出去”，不是因为管理水平跟不上，这其中我知道的有达到CMM3的企业，而是因为：
1.企业的核心关键系统不具有模块化、插件式开发的架构，在技术上就不存在这种可能性，没有清晰的封装完善的API接口。
从企业管理层不求有功、但求无过的心态，也不愿意出现万一出了问题，却界定不清责任的情况，究竟是核心系统的Bug，还是外包开发的插件造成的Bug？
2.即使是相对独立的系统，外包开发完成之后，或者无法方便地实现功能扩展，或者扩展就必须采取某些类似hack code的方法，可能引入潜在的风险。
解决信息孤岛、解决IT系统的异构性，使得IT系统可以互联互通，新系统的开发、旧系统的功能扩充可以有序、低成本地实现，这也是众多解决方案提供商争相自卖自夸的一个领域，首字母大写缩略语层出不穷、乱象纷呈：EAI、ETL、EII、MDA、MDI、SOA、BPEL……
在Web开发领域，受facebook开放应用的刺激，open api、portable data、open social graph、open id、cloud computing、utility/ubiquitous/on demand等概念密如夏日傍晚野外的蚊蚋袭来。
坦白说，我以前做过大量的系统整合类项目，其中典型的一个项目整合了140多个不同的IT系统，项目金额3800万。但如果让我自己给这类项目评估，勉强得 C 而已。
身边的很多朋友开始研究各种插件机制，Eclipse OSGi这样一个精巧的有些过度工程（Over Engineering）之嫌的框架从05年以来在多次偏Java的技术聚会中被提起。Drupal、eGallery2、WordPress的模块扩展机制也有一些偏PHP的朋友在孜孜不倦地探究学习。
未来的技术人员，走管理路线的将沿着“广”的方向发展，在模块/插件、可扩展性、适应性等领域；走技术路线的将沿着“深”的方向发展，在算法、高性能等领域。
结论：相对来说，做好软件外包项目，解决管理瓶颈易，实现开放架构难。
对外包公司而言，新劳动合同法的实施意味着行业的新一轮洗牌。 外包需要一个规范的市场，需要一个公平的交易平台，而新劳动法的规范恰恰提供了一个竞争有序的发展空间，优秀的外包公司将获得更多的机遇。
对企业而言，用好外包公司却不是一件简单的事情，特别是对软件外包等不同于简单劳动力密集型的工作。据我了解，国内银行和外资银行都赶在2008 年1月1 日的大限之前，把一批从事简单、重复劳动的服务人员转成了外包关系；而国内的一些所谓高科技企业却相反地把一批从事软件开发的PT（Part Time）员工予以转正，或者在08年的Q1都增加了技术开发职位的head count。
高层管理人员肯定清楚在《新劳动法》实施后正式员工的用人成本大大增加，那这么做的苦衷就是：企业自身的管理水平和管理能力不过硬，工作无法“包出去”。而且，工作要能够“包出去”，还要求企业的系统（软件、硬件）的架构具有开放性openess、可适应性flexibility、模块性 modularity。“包不出去”，说明企业在技术架构和管理水平上遇到了双重瓶颈。
一、管理瓶颈
IBM、SAP看到了机会，向企业推销自己的研发项目管理解决方案和工具，或者是人力资源关系全生命周期管理软件等。
另一方面，除了上述的重量级解决方案，一些轻量级的、敏捷的软件开发过程也大行其道。
二、技术瓶颈
整合是软件行业经久不衰的一个主题。
很多公司的工作之所以“包不出去”，不是因为管理水平跟不上，这其中我知道的有达到CMM3的企业，而是因为：
1.企业的核心关键系统不具有模块化、插件式开发的架构，在技术上就不存在这种可能性，没有清晰的封装完善的API接口。
从企业管理层不求有功、但求无过的心态，也不愿意出现万一出了问题，却界定不清责任的情况，究竟是核心系统的Bug，还是外包开发的插件造成的Bug？
2.即使是相对独立的系统，外包开发完成之后，或者无法方便地实现功能扩展，或者扩展就必须采取某些类似hack code的方法，可能引入潜在的风险。
解决信息孤岛、解决IT系统的异构性，使得IT系统可以互联互通，新系统的开发、旧系统的功能扩充可以有序、低成本地实现，这也是众多解决方案提供商争相自卖自夸的一个领域，首字母大写缩略语层出不穷、乱象纷呈：EAI、ETL、EII、MDA、MDI、SOA、BPEL……
在Web开发领域，受facebook开放应用的刺激，open api、portable data、open social graph、open id、cloud computing、utility/ubiquitous/on demand等概念密如夏日傍晚野外的蚊蚋袭来。
坦白说，我以前做过大量的系统整合类项目，其中典型的一个项目整合了140多个不同的IT系统，项目金额3800万。但如果让我自己给这类项目评估，勉强得 C 而已。
身边的很多朋友开始研究各种插件机制，Eclipse OSGi这样一个精巧的有些过度工程（Over Engineering）之嫌的框架从05年以来在多次偏Java的技术聚会中被提起。Drupal、eGallery2、WordPress的模块扩展机制也有一些偏PHP的朋友在孜孜不倦地探究学习。
未来的技术人员，走管理路线的将沿着“广”的方向发展，在模块/插件、可扩展性、适应性等领域；走技术路线的将沿着“深”的方向发展，在算法、高性能等领域。
结论：相对来说，做好软件外包项目，解决管理瓶颈易，实现开放架构难。
用户评论