ControlTower物流服务新的解决方案复习课程.docx
《ControlTower物流服务新的解决方案复习课程.docx》由会员分享，可在线阅读，更多相关《ControlTower物流服务新的解决方案复习课程.docx（8页珍藏版）》请在冰豆网上搜索。
ControlTower物流服务新的解决方案复习课程
ControlTower
中远网络物流科技有限公司制订
2012年2月
1.业务发展背景
随着物流、供应链业务的发展，物流行业的竞争逐渐从价格的竞争向服务的竞争过度，谁能够提供丰富、周到、快捷的物流服务，谁就能够摆脱惨烈的低价竞争，获得优质客户，取得优势地位，也就掌握了企业发展的机会。
从客户（货主）、物流公司、生产商等来看，对货物的整个运输过程的掌控要求越来越严格。
对运输过程中的各种相关的事件、地点、状态等的要求更加明确，精度要求更高，响应速度要求更快。
同时，相应的附加服务也在逐渐增加，例如：
报表、KPI、流程定制、异常处理，甚至包括一些业务BI功能，都逐渐外包给专业的物流公司。
从物流公司、物流信息平台等自身来看，如何提供优质服务，留住老客户、吸引新客户，成为首要问题。
谁对物流服务理解越深入，就越能够在物流服务的规划、信息平台的建设中，融入更先进的理念、更合理的系统设计，进而提供更好的物流服务，谁就有基础在竞争中胜利。
IT技术的进步，出现了一种新的解决方案-ControlTower（简称CT），为这种对物流服务的迫切要求，找到了出路。
这种新的解决方案对于供应链的管理，带来了前所未有的灵活性，可以对供应链的相关业务按需配置、管理，并能对整个供应链的运行状态、货物状态进行监控，及时处理出现的异常情况，为物流客户提供全面、贴心的服务。
以中远物流为例，已经在实际项目中进行了CT应用，取得了良好的效果，确立了其在行业竞争中的优势，为后面争取更多的客户打下良好的基础。
随着CT的普及和实际应用在国内的推广，作为专业的物流公司、物流信息平台，如果我们不对CT进行深入的研究、开发，前面所获得的业务优势会很快丧失，因缺乏更加丰富、周到、快捷的物流服务，又会回到没有特色服务、价格竞争的阶段，造成企业盈利大幅下降，服务内容缺乏吸引力，逐渐丢失一些优质客户。
整个物流行业在CT方面，加强相关技术的研究力度，是行业发展的必然趋势。
CT技术研究，能够扩大物流公司、物流信息平台在技术、业务模式上的领先优势，保持在业务上的领先，为业务的拓展奠定一个坚实的技术基础。
2.
ControlTower三大特点
研究方案以可视、可控、可量化为指导原则，以灵活性、可扩展性、可重用性、独立性为目标。
2.1.可视化
首先，通过对业务流程的梳理，确定出在业务流程中需要监控的各个节点，以及相关的状态属性（时间、地点、状态值等）。
CT对这些确定的状态信息进行采集，作为整个CT的基础数据。
CT提供一个门户网站，允许每个用户根据自己的需要，自行定义、组合需要显示状态以及其他内容。
其次，CT提供对业务规则的支持，可以对业务规则产生的不同结果定义多种处理、展示方式。
在采集到状态以后，使用预先定义的业务规则进行校验、展示，如果出现预先规定的结果之外的情况，或者是预先定义的异常情况，CT能够支持多种方式（邮件、短信、传真、消息推送等），自动提醒相关角色、人员。
第三，能够展示各种图表、指标等数据，使用户能够直观的了解这个业务流程的运行状况，以及各个环节的效率等。
2.2.可控
当业务流程按照预先定义的环节正常运转时，CT只进行监控、展示等非干预性动作。
用户可以根据业务的变动情况，及时对CT需要采集的状态进行维护。
也可以对业务规则、业务流程进行维护。
在出现异常情况时，CT会触发预先定义的异常处理流程，自动执行一系列动作，包括：
通知相关角色、人员，执行异常情况下的业务流程，提供业务应对建议等。
2.3.可量化
可以在CT中自定义多种KPI指标，不同的报表，对整个业务过程和各个几点，进行多维度、不同深度的考核、总结。
3.ControlTower的主要功能
ControlTower主要包含基础功能和高级功能两部分，基础功能提供覆盖供应链这个过程的基础信息服务，包括：
状态跟踪、客户通知、客户查询、日志报表等；高级功能是CT优势所在，体现出CT的可视、可控、可度量，使之与传统的服务及跟踪系统区分开，包括：
KPI、异常事件处理、BI（报表、数据挖据、预测分析、辅助决策、流程规划）、SOP自动处理等，从各方面来提升客户服务水平，保留老客户发掘新客户。
3.1.状态跟踪
这是CT提供的最基本的功能，通过在系统中预先定义各种需要跟踪的对象及相关的业务系统，CT便可以自动采集这些对象相关的状态，包括发生的时间、发生的地点、相关的业务系统、当前状态。
采集后的状态数据，通过多种形式展现给客户，例如：
以流程跟踪的形式，动态展示流程上每一个环节的实时状态变化，使用户直观感受到整个业务链条的运行；以汇总的形式，使用户能够更方便的审视真个业务流程。
3.2.客户通知
对系统中采集的每一个状态值，设定该状态值需要自动通知、提醒的客户列表。
通知、提醒可以通过邮件、短信、传真等多种方式完成。
3.3.客户日志查询
能够通过日志系统，查询到CT及相关业务系统的运行状况，对可能出现的问题，提前进行准备。
3.4.日志报表
对CT系统、相关业务系统的运行情况，定期进行总结，可以是这个业务链条跟好的运行，提高系统运行效率。
3.5.KPI
CT从不同的业务系统获取所需的状态数据，在此基础之上，依靠强大的KPI系统，能够按照客户要求，定义各种与业务链条运行相关的PKI考核指标、方式，从多方面、多维度的考察企业自身、供应商，为业务决策提供强有力的支持。
3.6.异常事件处理
在CT上，可以对可预见和不可预见的意外情况（非正常状态值，或一系列状态经逻辑判断后的状态），定义一系列复杂的处理流程，是CT、业务系统、客户等各方面，在出现意外时，及时得到通知。
在此基础上，意外处理流程能够进行异常预案的自动处理，在最短的时间内控制意外的影响范围，减少由此产生的问题。
例如：
陆路运输过程中，出现天气异常情况，常规线路无法完成此次运输，CT会自动计算出新的运输线路方案，供决策人员选择。
3.7.BI（商业智能系统）
BI的加入，使CT站在了更高的起点。
主要包括：
报表、数据挖据、预测分析、辅助决策、流程规划。
这里的报表有别于传统上的报表，不是简单的数据汇总计算，而是根据系统里的各种业务模型，对整个业务链条的状况进行分析；数据挖掘是在统计报表的基础上，对每一项数据进行层层分析，找到该数据对应的最底层的数据来源，进而定位影响系统的根源；预测分析可以根据CT长期积累下来的基础数据，配合业务模型、业务人员的经验等多种因素，对今后一段时间内的业务发展趋势进行预测，并可以对业务人员对今后一段时间内人的企业发展方向，进行辅助决策；CT根据系统、外部的各种相关数据，结合预先定义的业务规则，可以自动提供业务人员多种优先条件下的流程安排，业务人员再根据需要选择，提高业务人员流程安排的效率和科学性。
3.8.SOP辅助处理
SOP是一个企业业务成熟的标志，一套完善的SOP体系，可以使企业的管理、运行始终处于一种高效、可控的状态之下。
SOP可以配置在CT中，通过CT的向导式操作指导，完美体现SOP的各个环节，在出现人员更替是，不会对系统运行、客户服务造成影响，能够完美的保持客户服务水平、保证服务质量。
3.9.丰富的展现方式
随着IT技术的进步，各种终端、沟通方式不断涌现，CT通过插件方式，满足最新出现的需求，实现服务的全面覆盖，丰富客户服务体验。
例如：
可以通过短信、彩信方式，向客户推送定制消息、通知；可以通过邮件方式，提醒客户各种系统事件；也可以通过微博方式，来广播系统的各种消息；还可以通过不同平台的客户端应用（iOS、Android等），提供用户随时了解业务运行状况的便利手段。
4.ControlTower应用方案
本方案以全国交通物流枢纽现有小件运输系统为例，描述CT与现有小件运输系统之间，如何配合完成小件运输整个过程的监控管理，并通过CT来提升小件运输系统的价值，为客户提供更丰富、更有价值的服务。
方案的原则为尽量减少对原有系统的改动，使原系统更简单、快捷的加入CT系统中。
在具体到每一个环节中，通过灵活设计兼容新、旧技术，来实现兼容原有系统，又能对新系统、新技术提供良好的支持。
4.1.1.通讯协议
基于目前已有的小件运输系统，CT在通讯协议上，支持HTTP/S、WebService、IBMWebsphereMQ；外部沟通方面，支持Email、SMS、FAX等。
在架构上隔离CT系统对具体协议的依赖性，预留统一、标准的通讯协议接口，能够在在系统实施、使用过程中，根据需要方便、快速的支持新出现的协议，减少对CT和应用系统的影响。
4.1.2.报文格式
报文格式基于XML标准，通过定义Schema来规范CT和各应用系统之间的数据传递。
Schema包含下列信息：
◆应用系统代码，由CT为每一个应用系统指定一个代码，用来在传递数据的过程中唯一标识该系统。
小件运输系统代码指定为：
LOGINKEXP。
◆认证信息，由用户名、密码两部分组成，均由CT分配给应用系统来使用，并进行定期更新。
系统初始分配的用户名和密码均为应用系统代码，在系统第一次登录CT后，由CT重新分配新的用户名和密码，并通知小件运输系统，由小件运输系统自行保存。
◆报文功能，包含了一系列的功能名称定义，每一个功能都代表CT与应用系统之间特定的一次数据交互。
由主功能码和子功能码两部分组成，主功能码用来确定不同的动作，子功能用来区分具体的工作内容、方式等。
主要的功能为：
i.系统登录LOGIN
主功功能名：
LOGIN。
该功能需要在报文中提供系统代码、用户名、密码。
子功能名：
a）FL（FirstLogin）：
首次登录，表明本次登录为首次登录，需要CT进行相应的初始化处理。
可以在应用系统首次登录CT时使用，也可以用来在应用系统发生变化后，通知CT重新进行相关的初始化工作。
只有真正的首次登录，登录信息中的用户名、密码是系统代码，其他情况下都需要提供由CT分配的用户名、密码。
b）NL（NormalLogin）：
正常登录，除了首次登录CT外，其他情况下登录。
ii.数据采集DAQ
主功能名：
DAQ
子功能名：
a）BASEINFO：
基础信息，用来获得应用系统的一些基础信息，例如：
状态数量、状态更新频率、应用系统功能列表、业务流程等；
b）STATUSINFO：
状态信息，是具体的业务状态的相关各属性值，包括时间、地点、业务状态值、相关业务人员、系统状态。
iii.系统状态查询SSINFO
主功能名：
SSINFO
子功能名：
a）BASEINFO：
系统基本信息，包括：
系统名称、系统代码、系统用户名称等。
b）STATUSINFO：
系统当前状态信息，CT用来掌握应用系统的运行状况，包括：
停止、运行、初始化。
iv.系统通知NOTIFY
主功能名：
NOTIFY
子功能名：
a）MSGINFO：
通知，CT向应用系统发送通知类消息，不需要应用系统进行相应。
b）WARNINFO：
警告，CT向应用系统进行报警，提示可能会出现的问题，应用系统可以根据该报警信息执行相应的动作。
c）ERRORINFO：
错误，CT向应用系统通知错误信心，应用系统必须进行相应，把结果反馈给CT。
d）ACTINFO：
动作通知，应用系统接到通知后，执行CT指定的工作，并把结果反馈给CT。
4.1.3.数据采集
主要采集系统信息和状态信息，CT通过系统信息来了解应用系统的状况，以便在特殊情况下采取一些应多措施。
例如：
如果得知应用系统宕机，则CT可以通过预警系统通过相关的人员、系统及时进行处理，调整业务流程等。
状态信息，是CT关注的核心数据，包含了每个业务过程中，详细的状态，包括：
时间、地点、业务状态值、业务系统操作员、系统状态。
通过一系列的状态信息组合，反映出该业务运行情况，在此基础上，可以进行一系列的BI、管理等操作。
首先，定义标准的状态对象，通过该状态对象，屏蔽不同系统、不同状态之间的差异，简化CT处理流程和工作量。
该标准对象包括：
状态基本属性（名称、所属系统、状态描述、状态类型、时间、地点、状态值、业务系统状态、业务系统操作员、优先级）、扩展属性。
其次，定义标准的数据采集接口，通过这些接口可以完成状态数据的定义、采集、保存、查询。
定义是指在CT中记录各业务系统的状态，可以通过录入界面人工完成，也可以通过数据采集接口自动完成（需要业务系统进行改造，支持相应接口）；采集就是通过系统的采集接口，按照预先设置的通讯协议、报文标准，从业务系统获得状态数据，可以是CT主动发送采集请求，也可以是业务系统主动上报状态数据；保存是把CT获得的状态数据存入数据库和更新数据缓存，出发相应展示页面自动更新，并通过规则引擎对数据进行检查，如果发现该状态异常或该状态所在的业务流程异常，则自动触发异常处理流程；查询主要满足CT展示系统、其他外部系统对状态数据的需要，查询通过缓存机制，减少数据库操作，提高响应效率。
4.1.4.状态展现
主要有两种主要展现类型：
静态展示、动态展示。
◆静态展示
提高多种数据查询方式，可以按照系统、状态类型、时间段、地点、业务流程等，不同的维度展现查询结果。
主要用于状态查询结果、报表等，其查询结果只包含当时CT中已经获得的状态数据，不会对其后发生的状态进行处理。
所提供的界面效果包括：
饼图、柱状图、表格等；
◆动态展示
按照业务流程、业务环节、业务系统等，设置不同的业务范围，对相应的状态进行实时的监控，任何一个状态发生变化，在相关的界面中实时更新，，如果有异常发生，则会有异常提示，通过该异常提示可以进入异常处理流流程。
所提供的界面效果包括：
业务流程图、业务环节放大显示图、多业务跟踪图等。
4.1.5.KPI
KPI系统提供灵活的指标定义、公式编辑、规则引用，可以对每一个状态数据、每一个业务流程等，从多个维度进行考核。
◆指标定义：
指标分为两类，一类是简单指标，用来对具体的单一的状态数据进行考核，通过业务流程或状态类型来选择需要考核的状态；另一类是复合指标，根据考核的需要，把多个状态项通过公式进行组合，形成一个新的考核指标，为了保证系统的性能，复合指标所包含的状态项数量限定在10个之内。
◆公式编辑：
利用友好的界面，对KPI所需要的公式进行维护，包括：
数学运算、逻辑运算，同时KPI系统提供解析器、运算器，对编辑并保存的公式进行解析、运算，得到KPI的结果。
◆规则引用：
在有些情况下，通过运算无法得到想要的KPI考核结果，而需要通过复杂的业务处理过程才能获得满意的KPI，这是就需要在KPI考核中引用规则引擎，通过规则引擎中的复杂规则运算来完成KPI考核。
4.1.6.预警、通知
CT在采集到状态数据后，同时进行三方面的处理，一方面保存数据、更新缓存系统；另一方面，调用KPI系统，对采集到的数据进行考核；第三，调用规则引擎，对数据进行业务规则教研，如果出现异常情况，则根据系统配置的异常处理流程，自动启动异常处理，包括：
通知相关人员（SMS、Email、电话等），执行与处理步骤（开始获取异常相关状态、调整数据采集频率、调整状态优先级等），发送通知给业务系统做相应处理等。
通知分为三类：
◆消息型：
此类通知包含简单的消息，不需要接受该消息的应用系统或CT做出响应，只需要解析消息、显示、保存即可。
◆警告型（预警）：
CT根据业务规则对新获得的和现有的数据进行业务逻辑分析（通过规则引擎），如果得到异常结果，则会出发系统与项配置的异常处理流程，该流程中可以通过配置警告信息，对相关连的业务系统发出警告。
业务系统收到警告信息，需要对此做出响应，并回复CT；同样，业务系统也可以发送警告信息给CT。
◆错误型
错误型是指CT通过规则引擎计算，得出比警告更严重的结果，即某一个、一系列业务出现问题，此时CT会自动通知相关的业务系统，业务系统在收到错误信息后，需要对此做出响应，并回复CT；相应的，如果是应用系统发生错误，则会发送错误信息给CT，CT收到消息后，进行相应的处理（例如：
标记应用系统状态、调整业务流程、调整业务环节等），并反馈业务系统。
◆动作型
是指CT需要业务系统配合，完成一些列操作，或者业务系统需要CT来帮助完成一些业务功能，则会发送动作型消息。
消息中包含：
系统名称、动作名称、动作参数等数据。
4.1.7.报表、BI
报表提供自定义架构，能够按照需要自定义统计报表（基于BI的报表，需要基于BI系统完成），包括：
格式、数据项、统计规则等。
CT提供一套标准的BI接口，在此基础上实现一定的BI功能；对于更高的BI要求，可以使用第三方BI中间件，替换掉系统自带的BI系统，已完成BI的平滑替换。
BI系统主要包括数据仓库建模、业务建模两大部分。
BI系统只是提供基本的BI功能，还需要根据具体的业务情况、业务系统数据，来完成业务建模、数据仓库建模。
数据仓库建模完成从不同业务系统抽取业务数据的规则，业务建模则在数据仓库的基础上，进行数据挖掘、分析等BI操作。
升级会员 