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

来源
：安全自动化

对于一卡通系统

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

，无法实现标准化。很多经验丰富的项目经理都曾经有过坎坷的经历
，即使智能化老司机有时也是挺犯怵的
。
文/ 仪创科技总经理 谢有生
对此现象产生的原因及应对方案，仪创科技有以下理解：
一
、系统架构反映的是组织架构
做系统设计的同学都知道康威定律。康威定律是马尔文·康威1967提出的
：“设计系统的架构受制于产生这些设计的组织的沟通结构。”通俗的来讲
：产品必然是其(人员)组织沟通结构的缩影
。
建筑智能化通常包含十几个子系统
，然而在与用户组织架构联系的紧密程度上，没有一个系统能和智能一卡通系统相比。
一卡通系统发卡中心承担实体卡、虚拟卡(人脸、指纹、二维码、NFC)的发行
，与各单位组织层次代码、职务职级编码
、个人信息需要精确匹配。
一卡通系统中的基本应用包含出入口的人行、车行
、消费的内容、规则、支付等各应用模块设计及使用，而用户在人力资源

、保卫、交通、后勤保障、技术等部门设置

、职能分配的差异化，势必造成一卡通系统模块划分、权限的个性化需求。
二
、软件功能、硬件性能的目标是场景化配置
软件、硬件在具体落地上

，也面临适配个性化场景
。同样是大院出入口，园区性质
、哨位配置、人流
、车流的管理模式不同带来众多方案的差异;同样是门禁点
，门的种类

、授权
、审批

、通行方式
、温度
、湿度、采光等环境因素，对硬件选型
、软件功能的要求各有侧重点
。同样是手机一卡通APP，是采用设备商通用一卡通APP
，还是用户自建
，甚至与用户移动办公整合
，都存在各种不确定性
。
此外
，任何一个一卡通新系统的建设也有需要必须继承的历史负担
，同时
，一卡通也不是孤立的
，需要与安防
、消防、园区智慧大脑、大数据服务平台等互联互通
。
从上可见，“每个智能一卡通系统都是独一无二的”是无法回避的客观要求。对此客观存在，作为方案商有什么应对方案呢?主要思路有两条:
1
、行业细分解决方案
从大的分类来说，一卡通系统可细分为政企一卡通、校园一卡通
、社区一卡通
、公共服务类建筑一卡通
。而公共服务类建筑也在细分为：科技园区
、产业园区、医院、轨道交通、酒店、商业综合体等行业专属特性。政企一卡通也分为单体建筑、园区、集团全国一卡通等不同层级需求。
企业可以根据自己的特长
，选择主攻方向。
2、中台+微服务的系统架构
在行业细分解决方案的具体建设中
，选择一个什么系统架构，既可以及时响应不断涌现的用户个性化新需求
，又减少系统的重复开发。
目前各位CTO大佬们推荐的思路是
：中台+微服务
。中台本质是共性业务能力下沉并形成可共享服务API接口再统一开放。微服务本质是单体应用的模块化拆分和轻量化接口协同。
中台属于横向打通，微服务属于纵向渗透
，两者相互结合
，是目前的最佳实践
。
总之：一卡通系统表面上的碎片化背后
，还是有相对稳定的共性底层逻辑。行业细分解决方案和中台+微服务系统架构是可行的二项应对策略。
但由于一卡通业务领域建模和数据治理的行业性
、专业性太强
，这类人才大概率只能在企业长期的实战沉淀中内部培养。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。