真正可信的数字，不是五个应用里“看起来最合理”的那个，而是能追溯到同一位会友、同一次登记和同一个时间点的记录。数字互相冲突时，先停止汇总，再确认每个数字如何产生、何时更新，以及是否重复计算。
1999年，位于加利福尼亚州帕萨迪纳的美国宇航局喷气推进实验室正在追踪“火星气候轨道器”。导航数据已经出现偏差，但不同团队使用的计算结果没有形成一致判断。任务团队仍需决定，究竟该相信哪组数字，并据此控制航天器进入火星轨道。
随后，地面失去了与航天器的联系。
美国宇航局的《火星气候轨道器事故调查委员会第一阶段报告》记录了原因：洛克希德·马丁的软件以磅力秒提供推进器冲量数据，喷气推进实验室的导航软件却按牛顿秒读取。两个系统都有数字，两个系统也都在运行，可它们表达的并不是同一种东西。
事故调查委员会主席阿瑟·斯蒂芬森及其团队面对的核心问题，并不是某个数字有没有被录入，而是这些数字能否在同一套定义下相互核对。
教会的数据冲突往往也是这个形状，后果当然远没有航天任务那么严重，却足以影响牧养判断。
五个总数可能在回答五个不同的问题
一次聚会结束后，分堂牧师可能同时看到五个数字：报名系统显示已登记人数，二维码工具显示签到人数，巴士表格显示乘车人数，WhatsApp群里有同工报来的现场人数，财务或小组应用又显示另一批活跃会友。
这些数字未必有一个完全正确。更常见的情况是，它们各自统计了不同对象。
报名人数包含后来取消的人吗？二维码签到是否包括重复扫描？巴士名单里有没有只乘车却未参加聚会的人？现场手工统计按人头计算，还是按家庭计算？应用显示的是整个教会、某个分堂，还是某个时间段？
如果这些定义没有写清楚，牧师只能凭经验挑一个数字。数字越多，判断反而越像猜测。此前我们在[三个不同总数如何让埃西重新定义可信记录](/blog/zh-CN/教会出席数据-三个不同总数如何让埃西重新定义可信记录-46327462/)中讨论过，同一场聚会出现多个答案时，第一步应当是重建记录的来源，而不是求平均数。
先确定事实单位，再讨论哪个应用可信
解决冲突需要先确定教会真正想知道什么。
如果问题是“谁真正到场”，可信记录应落到具体会友和具体活动上，并包含签到时间、签到方式及可核对的登记信息。报名、乘车和收到通知都不能自动等同于到场。
如果问题是“还有多少巴士座位”，数据单位应是有效乘车登记，而不是活动总报名人数。如果问题是“哪些会友需要跟进”，名单应区分缺席、取消、重复档案和身份尚未匹配的人。
ChurchFlow把会议登记、二维码签到、电话查询、GPS验证、自助签到和巴士安排连接到会友记录上。管理员可以查看实时出席情况，重复签到会被阻止。这个结构的价值在于让团队沿着记录追问：这个数字由哪些人组成，每个人为什么被算进去？
它不会让历史表格自动变正确，也不能替代同工对身份异常的核实。散落在群聊和表格里的旧记录，仍然需要逐项对照。具体做法可参考[当出席记录散落在多个群聊和表格里，如何确认谁真正到场？](/blog/zh-CN/当出席记录散落在多个群聊和表格里-如何确认谁真正到场-cf2eaabd/)。
给每个关键数字留下一条可追溯路径
教会可以从一次活动开始，建立简单的数据规则。
先为每个指标写一句定义。例如，“到场人数”只计算成功签到且身份唯一的会友；“报名人数”保留取消状态，不把取消者计入有效报名；“巴士乘客数”按具体班次统计。
再指定一套主记录。其他应用可以发送通知、收集报名或方便现场协作，但最终结果应回写到同一位会友和同一次活动下。
最后，保留异常清单。重复姓名、无法匹配的电话号码、手工签到、临时换车和现场补录都需要单独复核。不要把异常悄悄塞进总数里。
火星气候轨道器事故留下的教训，不是“多检查一次数字”这么简单。真正危险的是，两个团队都拿着精确数字，却没有确认这些数字采用同一种单位。分堂牧师面对五个互相冲突的应用时，也应先统一定义和记录路径，再决定哪个数字能够支持探访、交通安排和下一次活动规划。
评论
暂无评论。