心急吃不了热豆腐，火大煲不成靓汤。大集中就好比是一道“佛跳墙”，还要-

　　门诊来访：税务

　　求诊方向：税务大集中

　　症状主诉：2002年8月，国家税务总局提出“金税”三期总体目标，其中“总局和省局高度集中处理信息”一句昭示了税务大集中课题进入实质论证和酝酿阶段。争论随即而至，大集中的必要性、启动时间表、操作模式以及后续引发的业务、机制调整等问题相继摆上桌面，争辩各方相持不下。说起来，金融大集中的成功探索多少也算是一颗定心丸儿，即使是照方抓药，这把把脉、定定神儿的功效总是有的。只是个体差异、自身“体质”过于偏离，模仿的路子越走越窄。今天，大集中的调子似乎是定了，各种难题好像作料般地恭候其旁，如何烹煮便成了最大的课题。

　　出诊医师：廖朝晖

　　医师名衔：神州数码软件有限公司政府事业部副总，主任系统分析师。

　　行医资质：1995～2002工作于国家税务总局信息中心，曾任国税总局CTAIS项目技术保障组组长、业务组副组长、综合组组长，总局信息化办公室技术组组长。具体负责CTAIS项目的系统需求编制、技术设计把关、技术测试和技术验收。他同时是国税总局税收业务分类代码的主要起草人，技术主持税务总局信息化建设一体化总体设计，决策支持系统总体框架设计以及“金税”三期工程总体技术框架设计。

　　「“非典”引子」

　　5月6日，杨姓邻居驱车北京平谷区尽纳税人之责，途经“关卡”，陈述、填表、试表、消毒后放行直达某税务所，然后，前述流程再现，终进得纳税大厅，工作人员口罩遮面各就各位，表情肃穆，眼神警惕，并令其不得近于两米，报表且放于桌上则可离开。杨纳税人也是聪明人，不好久留，快去快回。路上耽搁近2小时，申报共计逗留1分钟不足。只是归后发现，增值税发票购买要事早已忘于脑后。

　　5月8日，张姓朋友的老妈前往昌平区某税务部门纳税，远远地望见一大纸箱立于门口，近身后方知此乃收集报表之临时装置，纳税人只需将表放入其中则可速战速决。

　　仍是“非典”肆虐的5月，推迟进行的税务专访延期举行，其间谈起上述情节，不免唏嘘。

　　「诊断篇」

　　大集中的车一定要搭吗？

　　「医嘱」发展需要也好，借鉴他方经验也罢，税务大集中早晚也是个必选课题。但步子一定要放慢一些，既要兼顾税务信息化的历史，也要保证现有格局的稳步过渡。更通俗一点讲就是不妨试一试“中庸”的路子。

　　税务信息化搞了20年，从手工计算机模拟到大型数据库应用再到现阶段的电子税务，多变性贯穿始终。政策导向引发业务流程的改变，区域性需求差异又导致应用系统的多样性。而且，税务更强调过程控制和管理。诸如此类的因素，无疑抬高了税务应用的门槛。事实上，20年后的今天，无论是基础设施投入和架构还是应用平台和业务系统实施，仍以区域为限，各自单兵作战，资源无法共享。

　　2001年，国税总局在总结20年历程时注意到，缺乏统一规划和协调是造成前述表象问题的关键所在。功能交叉重复、数据口径冲突、设计体系、思路千差万别的业务系统一旦平铺到各地税务机关，其用户便开始面临错综复杂的系统指向。在此背景下，国税总局及时成立了信息化办公室，总体统筹、协调业务和技术两方面的一体化设计和规划，以期修正第一阶段散兵游击式的作战模式。

　　数据大集中是否在上述指导思想下出台尚不得而知，事实上，目前它仍在争论和酝酿之中，只是作为未来发展的一个目标提交业界讨论。多年浸淫税务行业，神州数码一直有幸参与国税总局各种应用规划和框架的设计。根据自身经验分析，他们确信，无论是形势驱动还是业务发展所向，大集中都应该是现阶段税务变革的具体目标。廖朝晖则进一步解释了他的判断和观点，根据目前税务发展现状，他认为税务大集中推进的速度不会很快，启动的动作也不应该过大。毕竟，和金融机构相比，税务行业的水似乎更深一层，弄不好就会被呛到。实际上，目前国税总局也并未制定启动税务大集中的时间表，重点精力仍放在“金税”二期的收尾工程和“金税”三期的论征规划上。

　　此文开篇多次提到税务信息化的历史，20年的积累，抛开经验、教训不谈，仅仅是留下来的各种设施和系统就纷繁复杂得毫无头绪。所以廖朝晖屡次强调，“一口吃出个胖子”既不现实也不具操作性。具体到税务大集中，他认为可以考虑渐进方式实现：先是取消地市级的征管数据服务器，数据全部进入省级托管存储，对税源、信息量少的地市可以进行合并存储。但此时暂不急于打破各地现有的业务模式，以避免可能的动荡和不稳定。随着数据的省级汇聚，部分业务功能模块和原有机构格局必将逐步因适应上述变化而改变，从而实现真正意义上的省级大集中。

　　有顺风车可搭吗？

　　「医嘱」热火潮天的金融大集中给了其他行业跟进的希望。但技术框架的有章可循并不意味着业务框架的移植性，需要警惕的是，税务大集中的业务设计难度远远超越前者，业务框架更趋复杂。

　　抛开行业特性不谈，大集中的概念本是大同小异。况且，金融大集中搞了这么多年，总会有相似的体系和模式可供参考，从这个角度讲，税务大集中的难度似乎并不大。的确，无论是响应速度还是系统可靠性、安全性，金融行业的要求甚严，不夸张地讲，这些技术上的性能指标都是其致命因素所在。但对税务行业而言，上述略显苛刻的条件却允许有不同程度的“放松”。从这个角度上分析，在技术框架方面，金融大集中的选型、设计、布网等技术经验完全可以被借鉴一用。

　　转而分析业务层面的需求，情况似乎复杂得多。

　　银行也好，证券也罢，它们的业务流程更像是一种流水作业，每一笔业务的信息量相对较少，只需在第一时间响应后把相关金额、密码、账户、余额等数据信息记录下来即可，这个过程严格讲就是一个简单的事物处理过程，同期，数据分析和管理并不参与其中。就这个事物处理过程而言，系统的实时性、可靠性、安全性尤被重视。与之相比，税务业务关联的信息量却非常大，廖朝晖举了个例子：纳税人的一张增值税申报表，内含上百个字段，它同时又可能附带10几张附表，总体数据量可想而知。而且税务业务之间具有紧密的关联性，税务部门都需要对其进行“因果”监控。仅以税收征管信息系统为例，它不仅关心“果”，还关心“因”，目前阶段更关心“过程控制”。所以系统必须内置更多的管理理念。

　　事实上，如果仅关注上报的数据结果，税务大集中倒不是个难题了。因为从理论上讲，在国税总局构建一个超大型纳税网站，各地纳税人均可随时、随地上网纳税，实现申报的全国性集中并非天方夜谭，所以就申报一个“动作”而言，这种简单的事物性处理过程，实际上并没有太高的技术门槛可言。但问题是，它对税务机关却没有任何实质意义。从纳税过程看，纳税人发票购买情况、实际经营状况、报表数据真伪等相关行为和事件都需关联管控，即使是这样一个独立的申报系统，在大集中后也需要考虑其分析和管理等功能与报表数据的融合。

　　另外，金融业务大多以一笔交易为处理单位，而税务业务往往是在一个周期内完成的事物，很难确定一笔业务的起始和结束点。仍以申报为例，它以“月”为作业周期，应该纳税的金额、预交金额、补交税款等信息均需汇总处理，与银行单笔交易和处理过程相比，税务一笔业务的复杂程度明显偏高。

　　廖朝晖并未透露，以上因素是否正是引发税务大集中争论的焦点所在。他只是强调，说到底，这并不是一个“一拍脑袋瓜儿就能干好”的事情，很多难题和风险都要警惕。即使有前车之辙，若是不错毫厘地跟着走，劲儿倒是省了，方向性的失误，扭转起来就难了。

　　如何控制车速？

　　「医嘱」驾驶手动挡车的乐趣缘于换挡时车速的自如控制和加速时的快感。数据集中、业务集中、机构集中，就像是机动车的三个挡，启动、加速、再加速，然后便可体会风驰电掣向前冲的境界。当然，为免混乱，大家必要遵守一定的交通规则。技术和业务层面的统一规范和标准呼之待出。

　　目前，税务基本实现了地市级的数据集中，即在地市一级放置征管数据服务器进行数据的接收和存储，各种应用系统也开始在地市级集中的基础上推广应用，但省级和总局的集中仍在规划之中。在数据集中的基础上，业务处理的集中会逐步跟进。实际上，纳税人并不关心数据最终存储和处理位置的改变，但他们却关心诸如纳税地点、纳税方式的简捷和快速。省级数据集中的意义可以银行为例，正如省内或全国范围内的通存通兑一样，未来税务省级数据集中之后，一个最典型的变化就是，纳税人可不受税务机关地点所限，在最方便的地方、以自己喜欢的方式申报纳税。自然，纳税以及申报管理、数据处理等相关业务模式也会随即发生变化，从而引发业务处理的集中。再看税务机构的设置，目前是总局、省局、地市局、县区局，县区局下属各税务所的体系结构，级级收集和上报，到了省一级和国税总局，原则上已经不直接面对纳税人和具体事物，更多的是进行宏观调控和管理工作。省级数据集中后，全省的会计账单和纳税报表都可从其设置的大型数据库服务器上一次性输出、处理和分析，目前由各地市、县区一级完成的报表收集和上报工作全部可被压缩掉，随之而来的应是机构的集中，不必要的中间机构被重组，总局、省级管理层和基层工作人员届时可直接对话，整个管理流程同时被精简压缩，高效、透明的税务管理目标有了实现的可能。

　　当然，无论是哪个层次的大集中，两个最关键的问题均无法回避，即统一技术和业务层面的规范和标准。大而化之，廖朝晖的担忧则具体到了业务层面的指标口径体系和技术层面的代码标准问题。很严峻的一个事实是，目前各地数十个应用系统，因缺乏统一的指标口径，对相同一个概念的解释就会产生区域性的巨大差异。再谈税务代码，它的形成实际上是一个自下而上的过程，各地在推广应用过程中不断提出、不断完善、不断简化，在此基础上，总局先后颁布了几个版本，但现在看来，业务代码的实际应用范围，特别是代码的维护工作都没有得到彻底的落实。不同软件不同项目采用各异代码，显而易见，这将对未来的数据集中和业务重组带来严重的技术上的冲突。实际上，如果连最基本的数据口径和业务代码都未实现统一和规范，不但大集中很难推，现在讨论的集中之上的数据分析、数据仓库和挖掘更是空中楼阁。

　　「处方篇」

　　内功练好出手快

　　廖朝晖目前的身份是神州数码软件有限公司政府事业部副总经理，主任系统分析师，做了厂商的发言人，他更喜欢强调“练内功”的重要姓。事实上，神州数码软件公司今年的业务主线很明确，一个是大集中，一个是产品化。廖认为，产品化是任何一个软件公司规模发展、面对复杂多变的市场需求所做的必然选择，只有这样才能实质降低运维成本，而且尽可能地减弱人为因素的影响。众所周知，做行业应用软件的一个最突出问题就是缺人，常常是一个项目下来，临时编队，时间跨度大，工程师成就感小，人才一流失，项目就会面临停顿的风险，甚至屡被“克隆”。另一方面，目前大部分软件商被行业用户需求牵着鼻子走，类似税务多变的需求现实，一些开发商往往是无所适从，打一枪换一地儿。产品化策略最大的好处其实最终是传递给了用户，能够走在用户需求之前，完成系列产品的调研和框架设计，并为用户提供高端的咨询服务。换言之，产品化会大大降低软件开发周期，快速提高软件企业的应变能力，对于大部分政府部门信息化项目而言，这一点也许将成为应用软件开发商制胜之关键。

　　公用平台显山露水

　　根据国税总局“金税”三期工程“集中、共享、服务”的具体目标，神州数码软件有限公司确立了三个方向上的创新课题，一个是税务业务流程优化和重组，一个是开放式税务应用支撑平台的研发，一个是大型税务数据库建设和管理。其中开放式税务应用支撑平台的开发成功被认为是神州数码软件公司产品化策略的具体体现。这个基于JAVA的开放性平台，最底层是各个行业均可以共用的基础平台，在此之上，是专门针对税务业务的共性开发的税务应用平台，最上一层则是各项专门税务应用系统。这个分层搭建的支撑平台，可面向用户端进行二次开发，很方便地把外围产品、网站、门户、多元化报税等应用整合在一起。据廖朝晖透露，目前深圳国税局正在应用这个平台进行核心征管系统的优化和升级，预计10月份便可上线。

　　另一方面，基于“中国税收征管信息系统（CTAIS）”开发的税务中间件产品CDAP同时推出，该平台实际上是一个基于XML开发的公用数据交换平台，可主要面向Internet构建多元化电子报税的重要支撑平台，集数据采集、纳税服务为一体。CDAP可以与各地区、各种纳税应用系统实现有效衔接，从而预留利益空间给各类渠道服务厂商。

　　作为处方，上面提到的思路和产品看上去似乎距离大集中有些远，一开始，记者甚至不敢苟同他们的“税务大集中解决方案”的宣传用语。虽然参与了“金税”三期工程的论证规划设计工作，廖朝晖对于大集中的细节仍是讳莫如深。谈到记者的疑问，他换了个角度：大集中虽未正式启动，但发展态势已经初现，依神州数码在税务行业浸淫多年的经验，目前正在做的一些产品开发和产品化推进工作，都可以看做是在为大集中做准备。而且上面提到的一些公用支撑平台产品，是依据国税总局已经明确的发展方向和既定的中间件产品选型基础上开发而成，技术本身具有极强的扩展性，完全可以适应随时而至的大集中需求。

　　其实通俗点理解，也许可以把它们看做是一类中医处方，虽非头痛医头，倒可标本兼治。

　　记者点评

　　馍得一口口地吃

　　六七年前，常和税务机关打交道，排不完的长队、看不够的冷脸。效率、服务只是茶余奢谈。此次重温税务发展历史，想来那时他们也算是一只脚踏进了信息化的门，计算机模拟手工操作正是如火如荼地推行着，只是这装备先进了，队却越发得长了。于是有人感叹，扛着洋枪洋炮，以前只是对付人，现如今却还要对付机器，劳力又劳心。回过头再看，依当时的基础和认识，手工业务的计算机模拟也是不得不走的路，效果差强人意，启发总是有的，至少今天再作战略规划时能够兼顾一下系统的效率和效果。

　　行笔至此，似乎有些跑题。

　　大集中，又一个耳熟能详的词儿，跟着行业打天下，转眼间就要在税务领域扎营结寨。可国税总局此时却不动声色。香喷喷的馍上了桌，却不急于下嘴，定力有余。事实上，“金税”二期工程收尾、征管系统优化以及二者之间的整合方案等，每个都迫切，哪个都得细思量。况且，一些基础的规范和标准尚待统一，若是踉踉跄跄地直奔了大集中，即使途中不栽跟头，抢了馍囫囵吞下，被噎着了也说不定。

　　廖朝晖总说“不能一口吃个胖子”，7年国税总局工作的经历，他深知其中的“水深水浅”。20年税务信息化的历史，有教训也有成就，继承和发展，总是个大课题。总局方面倾向于多条腿走路，而且要扎扎实实地走。道理说来不复杂，做好眼前的事儿断是不能妨碍了人们对大集中这个美好蓝图的向往和描绘。