如何解决一卡通系统非标准化问题?

来源：安全自动化

对于一卡通系统，建筑智能化从业者最大的感叹是碎片化
，每个用户多多少少都有定制的内容

，无法实现标准化
。很多经验丰富的项目经理都曾经有过坎坷的经历，即使智能化老司机有时也是挺犯怵的。
文/ 仪创科技总经理 谢有生
对此现象产生的原因及应对方案，仪创科技有以下理解：
一、系统架构反映的是组织架构
做系统设计的同学都知道康威定律

。康威定律是马尔文·康威1967提出的
：“设计系统的架构受制于产生这些设计的组织的沟通结构
。”通俗的来讲：产品必然是其(人员)组织沟通结构的缩影。
建筑智能化通常包含十几个子系统，然而在与用户组织架构联系的紧密程度上
，没有一个系统能和智能一卡通系统相比。
一卡通系统发卡中心承担实体卡、虚拟卡(人脸

、指纹、二维码、NFC)的发行
，与各单位组织层次代码、职务职级编码、个人信息需要精确匹配。
一卡通系统中的基本应用包含出入口的人行、车行
、消费的内容、规则、支付等各应用模块设计及使用，而用户在人力资源

、保卫、交通
、后勤保障
、技术等部门设置
、职能分配的差异化，势必造成一卡通系统模块划分
、权限的个性化需求。
二
、软件功能、硬件性能的目标是场景化配置
软件、硬件在具体落地上，也面临适配个性化场景。同样是大院出入口
，园区性质、哨位配置、人流
、车流的管理模式不同带来众多方案的差异;同样是门禁点，门的种类、授权、审批、通行方式、温度
、湿度、采光等环境因素，对硬件选型、软件功能的要求各有侧重点。同样是手机一卡通APP，是采用设备商通用一卡通APP
，还是用户自建
，甚至与用户移动办公整合，都存在各种不确定性。
此外，任何一个一卡通新系统的建设也有需要必须继承的历史负担，同时
，一卡通也不是孤立的，需要与安防、消防、园区智慧大脑、大数据服务平台等互联互通。
从上可见，“每个智能一卡通系统都是独一无二的”是无法回避的客观要求
。对此客观存在
，作为方案商有什么应对方案呢?主要思路有两条:
1
、行业细分解决方案
从大的分类来说，一卡通系统可细分为政企一卡通、校园一卡通
、社区一卡通、公共服务类建筑一卡通

。而公共服务类建筑也在细分为

：科技园区
、产业园区
、医院
、轨道交通、酒店、商业综合体等行业专属特性。政企一卡通也分为单体建筑、园区、集团全国一卡通等不同层级需求。
企业可以根据自己的特长
，选择主攻方向
。
2
、中台+微服务的系统架构
在行业细分解决方案的具体建设中，选择一个什么系统架构，既可以及时响应不断涌现的用户个性化新需求，又减少系统的重复开发。
目前各位CTO大佬们推荐的思路是：中台+微服务。中台本质是共性业务能力下沉并形成可共享服务API接口再统一开放
。微服务本质是单体应用的模块化拆分和轻量化接口协同

。
中台属于横向打通，微服务属于纵向渗透，两者相互结合
，是目前的最佳实践
。
总之：一卡通系统表面上的碎片化背后，还是有相对稳定的共性底层逻辑。行业细分解决方案和中台+微服务系统架构是可行的二项应对策略
。
但由于一卡通业务领域建模和数据治理的行业性

、专业性太强
，这类人才大概率只能在企业长期的实战沉淀中内部培养
。
特别声明
：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布

，本平台仅提供信息存储服务
。