这套是干什么的
我们设计一整套以人员和权限为核心的门禁一卡通方案：组织架构怎么建、权限怎么分、考勤消费访客怎么统一、分几期上、数据怎么验。解决的是系统上线后人还是管不住、规则天天改、数据对不上这些事。
现场常见的问题
现场常见的毛病
系统上线了但规则没设计好，今天这个部门要改权限，明天那个人要加门，天天在改。
现场常见的毛病
门禁和考勤各建一套人，同一个人在两个系统里部门不一样，月底统计对不上。
现场常见的毛病
一上线就把所有功能全开，员工不会用，最后只用了开门这一项，消费和考勤闲置。
权限体系与组织架构
一卡通的核心是权限体系，我们按三层设计：人员层、角色层、门组层。人员归属于部门，部门是组织架构的基本单位；角色是权限的集合，比如车间工人、办公室职员、夜班保安、外包人员、访客五类；门组是门的集合，比如生产区门、办公区门、宿舍门、食堂消费机。授权是给人配角色、给角色配门组，不直接给人配门。这样来一个人，选角色就完事；来一批人，批量选角色。直接给人配门的做法，人一多就管不住，我们在方案里明确反对这种做法。
权限还要考虑时间和例外。时间模板按班次做：白班 8 点到 17 点、夜班 20 点到次日 8 点、全天候三类，门组加时间模板才生效。例外情况单独处理：临时加班的走临时授权（有起止时间，到期自动收回）、节假日统一调整、检修期间开放特定门。我们还会设计一套离职流程：人事发起停用，系统在当天 24 点前收回全部门禁和消费权限并保留历史记录，这一条要写进客户的管理制度，不然再好的系统也管不住人走权限还在的问题。
交付清单
交付清单包含：门禁控制器与读头、通道闸（可选）、消费机与充值方式、访客登记终端、发卡器与卡片、考勤规则模块、一卡通平台部署与授权、数据库脚本、服务器或虚拟机、网络与 UPS。文档给：组织架构表、角色与门组对照表、时间模板表、权限申请与变更流程、离职停用流程、分期实施清单、验收标准表。验收口径：按角色表逐个验证权限，抽查 5 个角色各 3 人；临时授权到期自动失效，实测 5 次；离职停用后 24 小时内相关权限失效；消费与考勤数据按人按日统计，与手工台账核对一致；权限变更有记录可查。
实施步骤
第一步制度先行，我们先和客户一起把权限管理办法定出来：谁能申请、谁审批、多久失效、离职怎么办，制度不定就上系统，后面必然乱。第二步建组织架构和角色表，这一步要人事部门参与，表做出来要他们确认。第三步分期实施：一期做门禁加考勤（这是最常用的两项），二期加消费，三期加访客和访客机。分期的好处是员工有时间适应，我们也有时间调规则。第四步批量导入人员并试跑，先用 20 人跑一周，发现问题再全量铺开。第五步培训分管理员和普通员工两批，员工只看怎么用卡和怎么查记录。第六步按验收标准表逐项验收。
运维与交接
交接给角色与门组对照表、权限变更流程、数据库备份脚本、操作手册和一份月度检查清单。数据库每天备份、保留 30 天，我们建议每月导出一份人员与权限的对照表存档，用于审计和追溯。权限变更要有记录，谁改的、改了什么、什么时候改的，系统里查得到。保修 12 个月，远程问题当天响应，仙桃城区 4 小时内到场。上线后三个月内我们提供一次规则复核，看哪些角色设多了、哪些门组没用上，帮客户收敛一次。
适用场所
适合有食堂和宿舍的中型工厂、寄宿制学校与培训机构、医院职工与实习生管理、机关单位大院、园区多企业共用设施、物流园区的司机与装卸人员管理。人数在 100 到 1000 之间最适合，人少用简单门禁即可，人多需要更细的分级授权。湖北境内仙桃、天门、潜江、荆州、武汉可上门实施，制度设计部分可以远程开会完成。
