客户关系与内部协作平台

这套平台服务于企业内部的客户管理与协同工作。它不仅记录客户和联系人，还要让销售机会、日常活动、出差、项目日志、费用审批和日历彼此关联，使管理者能够了解客户进展，同时保证不同岗位只能查看职责范围内的数据。

项目的难点不在于制作多少张表单，而在于把分散的人员活动组织成一条围绕客户持续推进、可以追踪责任的业务链。

职责与关键工作

我参与系统模块的设计、开发和维护，工作重点包括：

• 梳理客户、联系人、机会、项目、活动和出差之间的数据关系，减少信息分散与重复录入；
• 将活动费用、出差申请、问题跟进和项目日志设计为带有状态与责任人的业务对象，而不是普通备注；
• 落实菜单、功能和人员范围三层权限，使用户不仅“能否进入页面”受控，能够看到哪些客户与员工数据也受到约束；
• 基于 Java Web 分层架构完成业务功能、查询统计、附件和 Word/Excel 导出等模块开发；
• 在维护过程中识别文档、数据库与实际业务行为之间的差异，保证修改不会破坏既有流程。

从客户档案到协作闭环

客户信息是整套系统的起点，但真正有价值的是围绕客户形成的上下文。一次销售机会可以关联后续活动和项目；一次出差可以记录随行人员、现场问题和后续处理；项目日志则持续沉淀交付过程。

这样设计后，管理者看到的不再是一张静态客户表，而是客户当前处于什么阶段、由谁跟进、发生过哪些关键活动、还有什么问题未关闭。对一线人员而言，信息也不需要散落在个人文档、邮件和口头沟通中。

数据权限设计

企业协作系统最容易被低估的是数据可见范围。同一个功能页面，对部门负责人、项目成员和普通员工展示的数据并不相同。如果权限只控制菜单入口，用户仍可能通过查询或导出看到不属于自己的客户信息。

我在功能实现中将组织、角色、功能权限与“可控人员范围”结合：查询、详情和导出都依据当前用户的数据范围过滤。权限由此成为业务服务的一部分，而不是只在页面上隐藏按钮。

这项设计兼顾了协作与隔离。管理者能够跨人员查看进展，普通员工则只处理职责范围内的客户与任务，为后续更细粒度的数据授权打下基础。

工程实现与取舍

系统采用 JSP、Struts 2、Spring、Hibernate/JDBC 与 MySQL 的分层结构。页面负责交互，服务层组织事务和权限，数据访问层同时支持常规业务操作与复杂统计查询。这套结构适合当时企业内部系统的快速交付，也便于按客户、活动、出差和项目等领域模块分工开发。

在维护中，我重点保持业务规则与技术实现的边界：客户归属、审批状态和人员范围放在服务端统一判断；批量导出与附件操作则单独处理权限和资源消耗。这样可以减少页面逻辑分散造成的不一致，也让问题更容易定位。

项目价值

平台将客户管理从“保存联系方式”扩展为贯穿机会、活动、项目与内部审批的协作系统。我的工作集中在领域关系、流程状态、数据权限和模块实现上，既支持日常业务交付，也让我形成了对企业应用中“业务对象、组织责任与权限边界必须一起设计”的系统认识。