ENGINEERING
技术与工程做法
本页说明我们如何让系统稳定运作。内容刻意不堆叠技术名词：需要判断的是这些做法解决什么问题，而不是使用了哪些工具。
INTEGRATION
系统集成：让新旧系统之间数据相通
多数企业面临的问题不是没有系统，而是系统之间不相通。新建设的系统必须能与既有系统衔接，才不会再增加一个需要人工搬运数据的界面。
- 可对接的对象
- 支付、物流、政府机关申报平台、既有 ERP 与第三方 SaaS。只要对方提供 API 或能导出数据，即可对接。
- 完全封闭的旧系统
- 即使没有 API 仍有衔接方式。可采文件交换或定期转档处理，不需为了单一新功能重建整套系统。
- 设备端的数据回传
- 生产设备、传感器与量测仪器的状态可实时回传至系统，支持远程监控与自动告警，取代人工抄表与定时巡检。
- 一份数据、多个入口
- 官网、后台、App 与 LINE 共用同一份会员与订单数据。客户由哪个入口进入都对应同一笔记录，无须分别维护。
相关服务
定制化系统开发SECURITY
信息安全：明确界定谁能看到什么
内部系统的风险多半不在外部入侵，而在权限界线不清。信息安全的第一步是界定权限，而不是先采购设备。
- 按部门与职务管控权限
- 系统设计阶段即明确定义谁看得到哪些数据、能执行哪些动作。薪资、成本、客户名单这类敏感数据，不会因为共用同一套系统而全体可见。
- 网络层的防护
- 防火墙规则、对外连线管理与办公室网络架构一并规划，除了维持系统稳定，也避免防护从内部网络被绕过。
- 最小必要访问与记录
- 我们维护时仅在必要范围内访问数据，并保留查询记录。AI 应用亦适用同一原则：限定可访问的数据范围，查询内容可供稽核。
- 表单与账号的防滥用
- 对外表单以提交频率限制与隐藏字段阻挡自动程序，不采用需要辨识图片的验证码——阻挡自动程序不应以增加真人的操作负担为代价。
BACKUP & RECOVERY
备份与还原：关键在于能否确实恢复
有备份不等于能够恢复。不少企业是在需要还原的当下，才发现备份文件早已损毁，或无人熟悉还原程序。
- 定期备份，并实际演练还原
- 除排定备份外，另实际执行一次还原流程，确认数据可完整取回，且有人员熟悉操作程序。
- 架构选择的依据
- 我们以四个问题决定架构：数据一旦丢失需恢复到多久以前、高峰时段有多少人同时使用、法规是否限定数据存放位置、未来三年的数据量会增长到什么规模。四个答案齐备之后，架构通常只剩一个合理选项。
- 备份频率与保留份数
- 备份频率与保留份数依数据变动量与可承受的恢复范围规划，是否采异地备份则视数据的重要性与法规要求评估，并于交付文件中载明。
- 故障后的恢复目标
- 还原目标时间与可接受的数据遗失范围，于规划阶段依系统停机造成的实际影响一并订定，并以还原演练验证是否达得到。
相关服务
企业网络规划MAINTAINABILITY
可维护性：让系统长期仍改得动
系统真正的成本不在建设完成的当下，而在往后每一次调整的时候。无法调整的系统，最终只能整套重建。
- 先确认画面与规则再开发
- 将流程具体化为实际的画面与规则，经你确认后才进入开发。认知落差在设计阶段修正的成本最低，写成程序后才发现则代价最高。
- 分阶段交付
- 优先将影响最大的环节上线，使效益提早显现，其余功能再分阶段迭代。每个阶段都交付可实际操作的成果。
- 同一团队负责到底
- 自咨询至上线后维护皆不更换团队。新增一个字段或调整一段流程时，不需另有人员重新理解你的系统。
- 功能可随业务扩充
- 定制化系统一次建设、长期使用，功能可随业务持续扩充，不受套装软件既定逻辑的限制而只能回复「做不到」。
HOW WE DECIDE
我们的判断原则
同一项需求可以有多种做法。以下是我们判断的原则，多数情况下能降低你的整体支出。
- 既有设备优先沿用
- 先盘点现有设备的规格与状态，仅在性能不足、无法扩充或有安全隐患时建议更换，并附上理由与预估费用，不为了更换而更换。
- 不预设一律开发 App
- 使用频率低的预约与查询，LINE LIFF 免下载、免注册，开发与推广成本均低于 App。确有推送或设备功能需求时，才建议开发原生 App。
- AI 的回答范围受限
- 答案来源限定在你提供的知识库，查无数据时即回复「不确定」并转由真人接手。宁可回复不确定，也不让系统对客户提供未经确认的信息。
- 不为了云端而上云端
- 云端、自有服务器与混合架构的成本与风险会逐项列出后共同决定，而非预设每一套系统都应迁移上云。