自2006年以来，我们一直从事计费系统。 总计-超过12年。 我们开始与电视市场合作，现在我们的客户包括银行，移动运营商和互联网电视提供商。 计费系统本身已经从一种或多或少的简单电视解决方案发展到完全融合的计费方式，并有可能应用预付费方案。 在这段时间内，我们在计费的实施和支持方面设法填补了很多难题。 错误经常发生是因为客户不了解“物料”，并且开票开发人员不了解客户的担忧和需求。帐单不仅仅是计算器
长期以来，计费系统不仅保持了客户余额和账单。 它们已深深地集成到业务中：它们提供流量控制，管理提供服务访问的过程，为客户提供不同部分的费用报告-从最近一次付款之日起，为期一个月，一年。 另外，计费系统通常应支持许多用户余额：货币和多种材料（奖金，通话时间，千兆字节的流量等）。 更不用说会员计划和其他交叉销售选项。 所谓的现代融合计费。 之所以能够实现此功能，是因为归类器与其他模块和子系统（CRM，PRM，BPM等）集成在一起。 对于开发人员来说，这不是“秘密”知识。 正如他们所说，划分职能和规则。 但是对于计费用户，即使是技术熟练的用户，也很难直接与“计算器”进行通信，有时甚至是新的想法。
我们实践中的一个例子。 客户是一家小型但有前途的公司。 他们没有整个计费系统的预算；他们要求删除BPM模块（业务流程管理）。 我们必须致敬，在技术上有相当先进的家伙。 他们表示，他们将采用开源解决方案，进行配置，与系统集成。 我们同意了。 四个月后，他们“淹没”有关错误数据的技术支持电话。
BPM是一个系统，除其他外，在连接订户时，它会进行数据验证，并且在您完成所有必要的参数（技术和个人参数）之前，不会跳到下一步。 他们拒绝了BPM，只是为数据输入绘制了一个界面。 接受连接申请的人不是高薪专家，人员流动大，培训时间短。 自然，他们在输入数据时经常犯错误。 最重要的是-在月底，公司发行了帐单，而商品定价者缺少参数。 他“发誓”，给出错误消息。 客户致电支持。 最后，我们决定为它们提供默认设置的BPM。 他们都开始融合，我们的技术支持也减少了头痛。 现在，除非完全实施了BPM，否则我们根本不会出售帐单，除非已实施了BPM，并且有与其集成的选项。 如果客户没有足够的钱来支付最低所需的租金，我们将提供租金或租赁，并可能在五年内赎回。 或者，如果这是一家新兴公司，但很显然人们对此事很认真并且有发展前景，我们可以提供大黄计划。 无论如何，这为我们和客户公司的管理层保护了神经细胞。
灵活性是一个宽松的概念。
计费系统架构不当不仅会导致技术故障。 根据我们的经验，在70％的情况下，由于营销灵活性不足，因此需要替换结算信息。 电信市场现在已经饱和，公司只能通过排斥竞争对手来获得新客户。 即使是大型供应商，他们掌握了新的利基市场并扩大了它们的存在，也开始放弃了，上帝亲自下令市场上的新参与者以独特的报价吸引眼球。 一场真正的关税战正在展开。 在这里，市场营销人员已经抓紧了头脑：“我们将只能在7月之前推出您的新的创新性超级新年费率，” IT部门发出一条消息。
有什么问题 在极少数的计费系统中，例如，有一个单独的产品目录模块，可以很容易地将服务组合到包中并配置促销。 他操作的参数既可以是服务，也可以是个人参数，例如通话时间，交通套餐或合作伙伴提供的服务（所谓的第三方服务），例如电影票或出租车。 可以相信，产品目录通常是CRM系统的组成部分，而不是计费的。 但是即使如此，并非所有公司都有单独的CRM。 许多客户服务直接导致计费系统。 这意味着任何新服务，新资费，新促销活动以及IT人员都无需在设计人员中收集它，而只需添加字段并编写代码行。 现在，七月即将来临。
的确，营销人员通常不理解卖方的意思是说其系统“相当灵活”。 够了吗？ “ Kommersant”主要对产品上市时间，向市场发布服务所花费的时间感兴趣。 一旦客户代表（该地区的联邦运营商所在的地区运营商）的代表直接参加了介绍会，便向我们介绍了3例他们在国内无法意识到的竞争对手的案例。 他们提出了一个尖锐的问题：您可以在系统中配置多长时间？ 吹牛不是罪过-在演示文稿进行时，我们在测试环境中与他们一起立了一个案例。 通常，采用经过深思熟虑的体系结构，即对任何产品计费并使用产品目录，可以自定义任何包装或库存，并在2-3天之内推向市场，这还不包括营销和功能测试的时间。 最好在约会阶段检查这是否可以作为特定账单。 因为在很多情况下，在“足够灵活”的系统中设置新的关税实际上需要几个月的时间。
在集中化与自治之间
大型市场营销公司在市场营销和销售方面也面临着类似的问题，这些问题由于收购区域运营商而变得越来越大。 分行中的不同计费系统不允许，例如，立即在全国范围内发起大规模促销活动。 报告和分析遭受苦难：根本不可能从所有这些不同的系统中收集有关连接和服务使用的数据。 该问题的部分解决方案是伞式CRM，其中有一个产品目录。 一些公司就是这样做的-他们通过CRM进行交易，并在计费中收费。 为此，公司必须拥有真正先进的IT部门。 将以不同语言和不同原则编写的计费系统与单个CRM集成起来并非易事。
但是，分布式系统无法解决一个永恒的问题-这是实地的常见欺诈。 我们有几个这样的例子。 特别是在乌克兰，我们引入了集中式计费，从最近收购的区域分支机构传输数据。 迁移数据时，我们进行了一系列检查和比较，所有不一致性都落入了相应的报告中，然后客户公司的安全服务通常开始移动。 什么不在那里。 通过会计系统，“零”关税计划等将订户联系起来……发生了坦率的欺诈行为：公司被出售，订户收据被保留了一段时间以保留剩余细节。
单个结算中心的组织使所有这种情况透明化；在该地区，仅保留了订户信息服务功能，因此几乎没有欺诈的机会。 此外，庞大的客户群与单个系统相结合，使我们能够在完全不同的层次上分析和预测客户行为。 我们逐渐开始将基于机器学习的分析系统应用于如此大的数据。 例如，我们可以在客户群中确定“风险组”-那些不久将拒绝公司服务的人。 这由人们的付款方式，他们如何使用服务，他们的个人帐户，与呼叫中心进行通信，金额多少以及由于什么原因而被锁定而得到揭示。
没错，计费的集中化带来了其他问题。 区域分支机构必须保留一定的技术独立性。 否则，如果中央计费中心突然位于“访问区域之外”，则该地区的客户服务可能会受到影响。 我们以牺牲外围设备“偏移量”为代价来解决它：授权服务器，流量收集和处理元素，服务供应元素。 特别是对于移动运营商，我们的Forward Fusion平台可以离线收取服务费用，并等待直到连接恢复后才能将数据与计费中心同步。 同时，区域用户可能会注意到他们的个人帐户不可用，但是所提供服务不会降级。
Jack安装的服务器：数据存储在哪里？
关于如何以及在何处放置计费系统，有很多选项。 公司经常担心客户数据的安全性，他们自己购买服务器并将其安装在数据中心中。 但是并不是每个人都能提供优质的服务。 有时客户会破坏某件事，但他甚至不知道那件事在他身边。 致电技术支持部门，我们的管理员已经告诉他故障出在哪里，哪个服务器没有响应。 我们对系统进行了配置，以使其能够以多种方式不断“监视”正在维护的系统，并在出现问题时发出警报。 因此，我们可以提前通知您内存即将耗尽，或者重要进程的速度已降至正常以下。 但是不幸的是，这并不能消除不可抗力。
另一种选择是，当客户想要托管自己，而我们交付硬件和软件组合时，当客户希望我们为他安排对他至关重要的服务一定的性能时，便可以完成此操作。 在这种情况下，“硬件”的成本立即包括制造商提供的三年支持成本。 然后，他们拿着备件，如果有什么破损，那么他们的专家会在24小时内带备件去该地点并修复故障。
相反，在某些情况下，他们将服务器携带到我们经过Tier III认证的数据中心中。
另一个常见选择-我们完全租用一切。 然后，我们对硬件负全责-维护和按时增加所需容量。 因此，在某些时候，我们开始使用私有云。 如果增加了负载，我们将更改设置，并获得额外的计算能力。 无需无休止地为我们进行设备的非核心“升级”。 不幸的是，今天提供公共云服务的俄罗斯公司仍无法提供计费系统所需的保证性能水平。 他们可以托管网站，您可以部署在线商店或放置1C。 因此，我们仍然必须积极参与各种私有云的优化和测试解决方案，例如，我们最近开始使用OpenStack。
数据库：重要的是，不仅在哪里，而且如何
选择数据库进行计费的重要性很难被高估。 只有针对特定产品优化计费系统，才能实现高性能。 转发计费已针对使用两个DBMS（Oracle数据库和PostgreSQL）进行了优化。 去年，Forward Billing被包括在批准用于国有公司的俄罗斯软件注册中。 最近，有消息传出，注册管理机构将在六个月内开始排除基于外国DBMS的开发。 从国家的角度来看，这是可以理解的。 在几乎每天都有新的俄罗斯公司受到制裁的情况下，他们希望确保俄罗斯软件的完全独立性。 但是对于供应商而言，这带来了可观的额外成本。 我认为在这件事上，我们和其他市场一样，正在等待立法者在这方面做出更明确的解释，然后我们将调整战略。
SLA：设置优先级
在理想世界中的某个地方，来自供应商的技术支持水平由明确定义的SLA-服务水平协议（也称为服务水平协议）确定。 SLA与仅记录为客户设置的支持时间的合同有何不同？ 它阐明了服务的特定要求：收到申请的速度，解决问题的时间-以及如果不满足要求将对供应商处以罚款的系统。
实践证明，要使SLA成为调节客户与供应商之间关系的有效工具，客户将不得不进行一些分析工作。 您需要了解事件对于特定业务将如何变得至关重要，而哪些事件却不值得惊慌。 我们的大多数客户都以某种方式使用我们的基本SLA，这些基础SLA经过反复测试，并认为是最佳的。
部分事实是，购买小型现成的“盒装”计费解决方案的小公司在出现问题的情况下，最终会获得376个技术支持。 通常对于此类公司，在线论坛上该产品用户社区的帮助更加迅速。
没错，其他极端情况的确会发生。 一个潜在的客户，一个小型的虚拟移动运营商，在对计费系统的支持被严重“烧死”之后才来到我们这里。 结果，该客户向我们提供了“疯狂的” SLA，使我们对响应时间和罚款的标准要求增加了近一百倍。 不幸的是，我们无法说服他，他继续为订户提供服务，后果自负。