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

来源
：安全自动化

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

。同样是大院出入口，园区性质、哨位配置、人流、车流的管理模式不同带来众多方案的差异;同样是门禁点，门的种类、授权
、审批、通行方式、温度、湿度
、采光等环境因素
，对硬件选型
、软件功能的要求各有侧重点。同样是手机一卡通APP，是采用设备商通用一卡通APP
，还是用户自建
，甚至与用户移动办公整合
，都存在各种不确定性。
此外，任何一个一卡通新系统的建设也有需要必须继承的历史负担
，同时
，一卡通也不是孤立的，需要与安防、消防
、园区智慧大脑

、大数据服务平台等互联互通。
从上可见，“每个智能一卡通系统都是独一无二的”是无法回避的客观要求。对此客观存在，作为方案商有什么应对方案呢?主要思路有两条:
1、行业细分解决方案
从大的分类来说，一卡通系统可细分为政企一卡通

、校园一卡通、社区一卡通
、公共服务类建筑一卡通。而公共服务类建筑也在细分为：科技园区、产业园区
、医院、轨道交通
、酒店、商业综合体等行业专属特性。政企一卡通也分为单体建筑
、园区、集团全国一卡通等不同层级需求
。
企业可以根据自己的特长，选择主攻方向。
2、中台+微服务的系统架构
在行业细分解决方案的具体建设中，选择一个什么系统架构，既可以及时响应不断涌现的用户个性化新需求
，又减少系统的重复开发
。
目前各位CTO大佬们推荐的思路是：中台+微服务
。中台本质是共性业务能力下沉并形成可共享服务API接口再统一开放。微服务本质是单体应用的模块化拆分和轻量化接口协同。
中台属于横向打通，微服务属于纵向渗透，两者相互结合，是目前的最佳实践
。
总之：一卡通系统表面上的碎片化背后
，还是有相对稳定的共性底层逻辑。行业细分解决方案和中台+微服务系统架构是可行的二项应对策略
。
但由于一卡通业务领域建模和数据治理的行业性、专业性太强，这类人才大概率只能在企业长期的实战沉淀中内部培养
。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。