最近突然听闻集团公司要搞多出账周期，以实现“削峰填谷”。
这让我十分吃惊。
因为这个问题的背后，实际是支撑系统路线的选择问题。选择多出账周期的，往往就放弃实时计费。选择实时计费的，再做多出账周期纯属瞎折腾。很显然，十多年前，各省移动就选择了实时计费的道路。所以，我很奇怪，到现在却去折腾多出账周期干什么。
十年前，在第二版实时计费系统的开发过程中，我跟HP的几个“高级咨询顾问”就这个问题还大大地PK过，为此还特意写过一篇《多出账周期真的有必要吗》。
后来在做分析时，我也多次分析过业务办理的高峰和低谷问题。结论是：业务高峰的形成关键在于业务规则本身，而非支撑系统，削除高峰完全可以通过修改业务规则的方法来实现。事实上，通过多次规则调整，目前的波峰现象已经远不如当年显著。
所以，目前在BOSS系统里折腾多出账周期，纯属拿着大炮打蚊子。
=========================================================
附：多出账周期真的有必要吗
当前这套计费系统从1998年4月投入实际运行以来，已经有二年多了。在这二年里，实际通话的移动用户数已从最初的80万左右，发展到今天的300多万。月话单量也从当初的3亿2千万增长到今天的6亿5千万。在今后几年里，用户数和话单量仍然可能保持高速增长，因此计费系统的处理能力应能够适应这种业务高速发展的需要。在新系统开发中我们将计费处理能力的目标定为1000万用户，即要求计费系统，帐务系统，营业系统，收费系统等在性能上都能够满足全省1000万移动用户的计费和其他各种需求。面对如此大的用户量有人因此担心今后计费系统，帐务系统是不是来得及处理，每个月出帐时收费和催缴会不会忙不过来等等，所以就提出象某些国外运营商一样采用多出帐周期方式。那么，什么是多出帐周期呢？对于我们浙江移动，是否有采用多出帐周期的必要呢？一旦实行多出帐周期，会出现哪些问题呢？
首先我们应该了解一下底什么是多出帐周期。
多出帐周期的含义是：在用户入网时给用户指定或由用户在一定范围内选择一个出帐日期，这个用户每月的费用将在这一天被汇总并出帐，在当天或第二天开始缴费；有多少个这样的日期就称有多少个出帐周期，可能是几个或者十几个。例如有个运营商XXX，有500万用户，分5个周期出帐，分别在每个月的6日，12日，18日，24日，30日，平均每个周期对100万用户汇总并出帐。假设用户A，B，C，D，E分别属于这五个周期。到6日，计费系统把A用户最近一个月的内的话单进行汇总并出帐，到12日计费系统对B用户汇总并出帐，到18日，对C用户汇总并出帐……。
因此，多出帐周期实现的是一种计算作业的分摊，不仅能分摊计费，也能分摊出帐和收费，催缴等。与非实时计费相比，它把原来集中在月底做的工作分成多个出帐周期来做，提高了汇总和出帐的速度，提高了设备的利用率。与实时计费相比，多出帐周期的优点在于能分摊收费和催缴等工作。尽管如此，多出帐周期到底有没有必要呢？
1、计费系统
对于计费，当前的实时计费系统经过简单的扩容在性能上完全能满足1000万用户的计费需要，而且与多出帐周期相比，实时计费能把一个月的计费作业平摊到每一天，实现了更好的性能分摊。当前300万用户的计费采用了三台HP K570小型机，实际每天的计费作业大部分都在其中一台K570上完成，如果采用并行作业，这三台K570应完全能满足500万用户的计费需求。在新计费系统里，我们订了6台HP N CLASS的小型机，其性能至少是K570的2-3倍，因此在应用不变的情况下用3台N CLASS的小型机支持1000万用户的计费应该说是足够了。当然今后应用肯定会复杂一些，但是无论如何用6台N CLASS小型机实现1000万用户的计费在性能上应该是绰绰有余的。所以对于计费根本没有采用多出帐周期的必要。
2、账务系统
对于帐务系统，目前每天出一次帐并通过收费系统跟银行比对。由于帐务系统处理的数据量相对较少，其出帐速度应该不成问题。对于各地区存在的到每个月出帐时工作量大的问题，可以采取把有些工作每天做的办法，比如每天都查看一下有次无户，而不是等到月底再查。因此对于帐务系统，采用多出帐周期意义也不是很大。
3、用户缴费
对于用户缴费，在上收费系统之前，可能存在用户缴费难的问题。而现在越来越多的用户已经通过信用卡或其他一些方式缴费了，剩下来的那些现金缴费用户也可以跑到银行缴费，所以不存在用户缴费排长队的问题。对于有人担心的在月底大量现金缴费对营业系统造成很大压力以及收费系统忙不过来的问题，我们不妨从技术上一下。在极端情况下，一个地区有50万现金缴费用户在同一天缴费。这些缴费事务如果以批量来做，可能不到一个小时就完成了，因此影响性能的关键因素应该是大量的到数据库的连接。如果减少了这种连接数，就不会对营业系统造成重大影响。为减少连接数，可以采用Oracle8中SQL *NET8中的CONNECT MANAGER，或者在银行与营业系统之间采用TUXEDO等中间件，这两种办法都可以解决这个问题。收费系统的性能问题也类似，可以通过改进应用、设备升级、分布式处理、采用中间件等办法来解决当前存在的性能问题。所以在用户缴费方面没有采用多出帐周期的必要。
4、话费催缴
另外，对于话费催缴，目前利用短信平台和客服中心可以完全通过技术手段来实现催缴，根本不需要一个个打电话过去催缴，所以催缴工作量不会很大。对于目前存在的月底停机量非常大的问题，我觉得可以采取一些简单的办法来解决。对于信用卡用户，其停机没必要等到出帐时。对于现金用户，可以通过短信催缴提醒用户及时缴费。对需要停机的用户，可以根据这个用户的信用度来决定停机的先后，信用度低的先停，信用度高的后停，这样不仅合情合理，而且可以解决月底大片停机忙不过来的问题。所以对于催缴和停机有比多出帐周期更好的办法来解决当前存在的问题。
通过以上分析，可以得出的结论是：对计费，出帐，收费，催缴，停机等方面来说，没有采用多出帐周期的必要。退一步来考虑，如果一定要采用多出帐周期，那么会有什么后果呢？客观上讲，多出帐周期肯定会在某些方面带来一定好处，但肯定也会带来种种原来没有的问题。以下的几个问题在决定采用多出帐周期前一定要考虑清楚：
1. 假设本省用户分成三个出帐周期，出帐日分别为2日，11日和21日。第一个出帐周期用户的话单日期从上个月2日到这个月1日，第二个出帐周期用户的话单日期从上个月11日到这个月10日，第三个出帐周期用户的话单日期从上个月21日到这个月20日。出帐后这三个周期分别出各自的财务报表。这三个周期的报表在财务上如何合并呢？其他业务和统计分析报表呢？
2. 目前所有的结算报表以及大部分的统计分析报表基本上都是按月统计的，其时间范围为从上个月21日到这个月20日。这样势必在统计的时间范围上与出帐时统计的结果不一致，如何在这两部分之间进行核对呢？从系统开发角度考虑，为了应用简单一些，最好的办法是开发两套系统，两套数据，一套用于出帐，一套用于统计。因此对于计费多出帐周期可能不仅起不到负载平摊的作用，反而可能使性能代价加倍。计费系统开发和维护的工作量也会因此大大增加。
3. 多出帐周期计费要求从营业系统中取到客户资料以确定用户到底属于哪一个出帐周期。一旦由于某种原因没有及时取到资料或资料出错，那该怎么办？比如说一个用户在21日出帐，但在2日前其资料上可能是2号出帐，由于用户不知道错了因此没去缴费，所以有可能这个手机被停机。停机后用户一申告，我们发现了这个问题，这个时候帐已经出去了，我们又该怎样将这个用户调到另一个周期呢？
4. 如果采用多出帐周期，因此对于同样是杭州的用户，可能你11日缴费，我21日缴费。这是否会让已经习惯了每月在某一固定时间缴费的用户感到困惑呢？这样做可能给自己带来了方便，但是却给客户带来了麻烦和混乱，这是否符合公司以客户服务为中心的方针呢？
5. 对于实时计费，我们已经积累了将近三年的开发与维护经验，许多系统基本都在实时计费的前提下开发的。一旦采用多出帐周期，势必对全部系统都需要推倒重来，原来能实现的功能在多出帐周期里不一定能完成，比如与银行的实时比对。而我们对于多出帐周期没有任何经验，计费，帐务，财务等系统上到底该怎么做我们一点概念都没有。所以，采用多出帐周期将面临巨大的技术风险。在技术方面，从公司的实际出发，这是否可行呢？
总之，本人认为当前我们采用的实时计费方式完全可以满足今后的计费需要，因此根本没有采用多出帐周期的必要。而且从实现上讲实时计费是比多出帐周期功能更强，性能代价更低，技术更为先进的一种计费方式。如果一定要采用多出帐周期将会引发许多新问题，无论在开发还是维护上都将面临很大的风险。因此，本人建议本省计费继续采用原来的实时计费方式，而不是多出帐周期。