当技术玩得及格了后，也难以突破时，我们所关心的事情会转向业务知识，没有过硬的业务知识就难与客户沟通、难以拿下大合同，难以竞标取胜。
我们的客户通常会有一些实际问题，这些问题又往往比我们在设计时考虑的问题要更加复杂一些，当然也可以用一个人多账号的方式解决一人多职问题，但是那样实现的在实际工作上用起来难免有些不方便，虽然问题被简化了，但是无法根治问题。
先看一下数据库设计如下：用户账户表，保存了默认的公司部门信息，用户账户组织关系表，保存了，多职的兼任情况、其中强调了所担任的角色职务情况，当然还需要补充的，可以另加。
下图是 组织机构、部门表，是一个树形结构。
相应的管理配置界面如下参考：
一人多职问题又会影响到整个系统的如下环节
1：选人组件，选人、列表中的数据会发生一些变化。
2：哪个部门、公司、组织有哪些人的算法需要发生变化。
3：哪个角色有哪些人？哪些人在哪个角色？的算法会发生变化。
4：以组织机构为基础的数据集权限过滤函数需要发生变化，算法需要更新。
虽然表面上变化不是很大，但是会牵扯到很多其他相关页面、功能函数的变化，这些变化又可能会引起一定的不稳定因素，还要经过一段时间的严格测试实际使用过后，才会渐渐的沉淀下来，成为稳定可靠的良好软件组件。