什么是关键的，什么不是？
Berry在哈勒姆的办公室一角的黑板报上挂着一份活页便笺薄，长长的一直到纸的最后一页，在这张工作表上，有图表解释了这个SOA是如何运转的：红色字体代表系统，蓝色代表数据流，黑色代表各个系统的名字。由于解释SOA如何发挥作用以及让他的手下理解这种新的思考方式（强调服务而不是应用程序）是Berry现在最为艰巨的工作之一，所以在长达一年时间里他不让任何人碰乱那个便笺薄。
06年1月11日到12日，在为期两天的一次会议举行之前，Berry并没有认识到他正在让自己进入一个什么样的境地。这次会议在Zoete Inval 酒店的会议室举行，酒店横跨Coty的哈勒姆办公室街区。25个关键流程的头脑人物聚在一起，他们要制定那份整合计划，这些人来自财务、客服、分销以及IT等职能部门。这是他们当中很多人第一次碰面。
“我们并不是一家技术公司，我们不会写代码”，Berry告诉25位听众。
他继续讲解，SOA的关键点在于勾勒一张任务地图，这些任务由应用程序执行，任务的流程是公司在做业务过程中要遵循的线路。在技术层面上，这些任务（比如说按订单发货运输）从运行它们的系统的原始语言转化成用XML标准语言编写的服务。在业务流程层面上，这些服务能够四处移动，不受次数限制，不需要非得编写新代码就能形成新的应用程序。
Berry 告诉听众，第一天会议的目标就是让代表理解他们所使用的流程。接下来这些代表依次谈论了自己怎么工作以及如何使用他们各自的系统。这个过程走完之后，基本形成了一幅公司如何运转的图画。
完成兼并后的新公司共有5个配送中心，其中两个从UCI继承而来，一个在法国里尔，另外一个在纽约的Mount Olive，它们都在J.D. Edwards的平台上运行。德国的中心运行LM6平台，另外一个则是Ratioplan平台。北卡来罗纳的中心运行Oracle和COPs。Berry说，这些平台都“陈旧且疲惫不堪”。此外，每个国家的业务都有独特的流程特点（有时是技术特点），不得不加以考虑。
举个例子，意大利已经在使用SAP的系统，这是Coty最终要在全公司推广成为标准的方案选型。在当地，最大的客户通常都会在个人店铺直接下订单，并且希望货物能直接送到店铺里去。而在英国，运行的是一套来自JBA的遗留ERP系统，Coty在当地最大的客户Boots 药品销售连锁（Boots pharmacy chain）通过EDI下定单，并且要求货物运送到当地的中心仓储仓库。
还有更细小的差别需要这个整合项目必须同时给予满足，比如说标签格式重置。这个SOA项目必须辨认所有这些标签，然后把它们转化成通用的可读服务。
当天会议以一个正式的晚宴结束，第二天继续进行。第二天的议程主要集中在Coty将如何让这一切变成现实的问题上。“我们不必非得建立整个‘泰姬陵宫殿’，我们只需要一个屋顶而已”，Gary Gallant说，他是来自美国分部负责信息管理的副总裁，在UCI并购过程中进入公司。“举个例子说，我们可以说任何时候任何人都可以创建一个SKU（Stock Keeping Unit，最小存货单位），我们需要把它在每个系统里加以复制，但是然后就永远不再创建我们的go-live 日期了”。相反，Coty 把自己关注的重点集中在接触消费者的那些环节上，包括像仓库发送订单、发货通知单、帐单等等——Gallant称之为“订单管理必不可少的环节”。
这种关注面向客户的流程的做法以损害内部流程为代价。举个例子，Coty的业务领导人过去一直在每天收到一份有关销售跟踪和存货管理的报告。但是Berry决定，那些关新UCI产品的报告的整理必须等到6月30日之后才能进行。这在业务领导人那里是一个不受欢迎的决定，但是每日报告并不能直接影响到客户，虽然它们仍然像以前那么有用。
为了把混乱状况降至最低，Berry决定创建一个小型SOA项目团队，包括1名项目经理、4名IT主管和一位来自iWay欧洲公司的咨询师，甚至里面还有一个更小型的美国工作团队。已经铺设了SAP系统的国家则由埃森哲公司负责进行整合，埃森哲公司是Coty在SAP项目上的合作伙伴。Berry说组建小型团队是他做出过的最好的决策。
“有太多智囊人士会从相反的方面影响到你的决策，但是我们没有时间去停下来去思考每一种选择方案”，他说。小型团队不会给机构增加昂贵的人头费用，比如说不需要配备专属的办公区。更重要的是，小型团队的结构消除了指令到达的跨度和时间，否则Berry有可能无法及时且直接对“我们是否沿着正确或错误的轨迹前进”这些问题做出反馈。
整合！
接下来的3个月对项目团队和Coty的IT领导人们来说来说是紧张的3个月。按照Gallant的说法，打到美国的电话会经常在凌晨3点响起。
Coty花掉最初几个月时间用于勾勒流程图，从而决定哪些环节实际上是和客户直接接触，从而需要纳入整合的范围。实际上整合流程是简单的事情；一个团队成员就可以承担某个流程工作——比如说来自销售人员的订单通知的流程，这个团队成员可以描述流程的每个环节应该是什么状况，数据是否需要从欧洲格式转化成美国格式，订单需要引导至哪一个配送中心等等。由于应用程序被转化成了服务的形式，所以Coty的工作团队能够用拖放工具安装这些服务，而不需要重新写程序。
相应地，团队把大部分时间都放在测试工作上。很多情况下测试工作会在星期五、星期六和星期日完成。
有一次特殊的测试在Berry心里记忆犹新。当时是3月末，Coty计划4月1日在西班牙、法国和意大利上马SOA。当系统处理数百个订单的时候Berry一直在一旁观测。当天结束的时候，他打电话给德国的一个配送中心问情况怎么样，而当时那位经理说：“什么订单？你说的是什么？”
后来证实，系统无法计算出如何处理订单，于是把订单囤积下来，而不是释放到各处理中心或把订单信息返回发送方。于是项目团队重新设定了一条新的流程规则：如果订单不能送达配送中心，那么就要返回发送者。
Coty的团队还发现了其他的问题，不管大大小小，他们都在项目进程中予以解决。公司在4月份完成美国配送系统上线，5月份是英国和爱尔兰，7月份是德国、澳大利亚和瑞士，这三个国家的系统正好在财年刚刚结束的时候完成，那个时间也是项目的计划截止时间。
品味成功的甜美芬芳，这很大程度上归功于之前收购UCI后新产品带来的收入，Coty在2006年破了30亿美元的销售记录。与此同时，IT部门的工作成果也允许Coty在2007年财年7月份开始的时候对销售和市场队伍进行调整和整合。
不过，随着项目进度问题被IT部门解决掉，他们也距离工作结束的日子越来越远。现在IT部门必须返回去，把整合过程中忽略的那些细节全部弄清楚，比如说业务领导人希望得到的那些每日报告（他们现在拥有一个基于Web的工具，能给业务领导人提供任何想要的数据），以及对交易的实时监控（Coty现在能够清楚了解系统出问题的那一时刻的状况）。
也还有时间来反思这个项目。Berry说，如果还有一件事情自己能够重做，那就是严肃对待结束状态的架构（end-state architecture）的设计工作。由于这个项目所要求的疯狂速度，他认为自己没有时间停下来想一个好方案出来。相反，假设结束状态能够自然而然地自我进化，那么就能形成一个整体的系统架构。事实证明这是一个相对比较容易的过程，只需花费几天时间就可以制作一个工作蓝图。这使得他相当清楚地知道他需要替换什么样的技术，以及在什么时间进行替换。他建议：“尽早明确下来是上策”。
Coty 依然在就自己的全球SAP系统继续展开工作。在接下来几年时间，他将把财务、业务计划和一些生产制造模型在欧洲和美洲地区铺设起来。不管他们是否在任何地方需要使用另外一个系统，整合将会采用SOA来实现。
至于SOA本身，使用它做为整合的工具只是一个开始。最终Coty希望能够把SOA应用于商业智能，而且帮助公司转变成一个实时公司。
但是最最首要的是。“两家公司的整合最终可能不一定是最完美或最有效的，但是订单却总是在系统里进进出出”，Berry说。
现在他说：“为此我们正在做细微的调整”。
（IT经理世界）
