开贴分享云表开发适合”零售连锁系统“的人事和薪资核...
2015-12-17 13:47:45
32540
29
|
突然间想把这段时间做的这个系统做一个总结，也算是分享吧！开始之前，我觉得特别想感谢一些人，这些人在我学习云表并制作这个系统过程中，提供了非常大的帮助。排前两位的，是
张晨
和乐乐，张晨在我入门的那段时间，真算是手把手教呀，所以尊称他为老师，乐乐在系统原理方面给了我醍醐灌顶般的帮助，再就是jolin
，后期有啥问题的，我都会直接@
她，这样获得解答的效率最高，还有就是恐龙爷爷、湖边漫步、CC
这些人，在讨论问题的过程中让我收获很多。
另外说一说总结的方式，既然是总结，所以就不仅仅是展示一下具体表单，重点还在于回顾我的设计出发点-
为什么这么整、在制作过程碰到的问题及解决方法或思路、以及对云表的建议。所以这个贴会不断更新，楼数会比较多，分享进度可能也会比较慢。
好了，现在开始正题。。。
零售连锁的人事薪资系统，有两块业务，一是需要解决人员的入调离职问题，二是每家店的薪资填报核算和汇总问题：
第一个问题，用云表的业务公式很好解决，这让我想起六七年前用勤哲做这个事情的时候，那是相当痛苦，那个时候的表间公式来解决这个问题会非常的绕，到最后还是放弃，不过也因为那个时候玩这类的系统，打下了一些基础，更关键的是勤哲的学习手册非常完善，我是认认真真的看过很多遍，这让我学习云表的时候上手比较快。（题外话，云表的学习手册真得真得需要好好完善，这需要有专门的人员或小团队来编写和维护这个文档）
第二个问题，薪资核算模块是这个系统的难点。如果有接触过零售系统的同学就会知道，终端销售人员的薪资结构很复杂，有提成（通常会和销售额、个人达标率、店铺达标率、公私佣类型、职级挂钩）、有各种奖项（团队达标奖、个人达标奖、最高销售业务奖等）、有各种补贴、最麻烦的是调店和支援情况（人员会在不同店铺间调来调去）、然后还有各种汇总表（一家店铺的主体可能是分公司，也可能是不同的个体户，每一个主体在财务上都要分别核算。还有其他很多汇总表，比如区域核算人力成本等等等）。看吧，是满复杂呀。今天我能把这些问题解决的七七八八，用云表做成一个非常自动化的系统，我是非常非常自豪的，也非常非常意外云表的易用性。如果是六七年前的勤哲，我是碰都不敢碰这块业务的。（题外话，我虽然经常玩这类型应用，但我没有编程基础，一直都在服装行业做人力资源或销售管理。所以你会理解我的意外喜和自豪感）
先开这个头吧，还有正事要做，慢慢来！
|
+1
1
最近谁赞过
29条回帖
本帖最后由 木才 于 2015-12-18 17:10 编辑
一、系统规划 先从系统规划说起。总结这段时间的经验和云表特点，像这样的小系统，我会划分为：参数设置、基础信息/档案、业务表单、查询报表和操作导航五个部分。其中有几点值得说一说： 1、参数设置 我原来所有参数设置是放到一个文件夹中的，但后来整理的时候发现，有些参数相对固定，你设置一次以后，相当长一段时间，比如说半年一年的都不需要动，比如说这套系统里的一些薪资政策的设置（如何提成，几个相对固定的奖金）、每月计薪天数等，一般这部分参数设置的权限会限定为系统管理员。还有些参数会经常性变化，需要日常维护，比如说新增店铺和店铺主体等，这部分数据是需要指定人员来维护的。 2、基础信息或者叫基础档案 我原来基础信息里只有员工档案，那个月度薪资存档是后来加进来的。为什么要加进来呢？其中有两个原因，一是我业务表单里的薪资核算表的布局比较散，信息量也很大，而大家都知道，人事这个环节核算完薪资表后，还是需要提交给财务的，所以当时我就想做一个中间表，按财务要求的规范和信息来做，用业务公式获取核算表的数据。这个原因，当时是主要原因，但现在回顾来看，我把它列为次要原因。最主要的原因，是下面这个。在薪资核算表里，需要从员工档案表里带出员工信息，其中一些员工信息，是作为各类薪资汇总表的依据，比如所这个员工的社保是在哪个主体里买的，要命的是，这个信息是在变的。万一我核算的时候是A，后来变成了B，我又去刷新了一个薪资核算表，我在做汇总的时候，就变成了B，汇总表和核算表就对应不上了。虽然这是非常例外的情况，但为了防止这种万一，我想到了要一个中间表来存放我进行核算那个时刻的所有状态，这个中间表的数据是相对固定的。我所有汇总表的依据，也是从这个中间表来做。但说了这么多，下面这个信息才是重点，是重点，是重点，就是乐乐说过的“任何一个系统都会有管理对象”，而我认为这个管理对象就适合在基础信息里体现，比如说人事变动的管理对象是人，所以有一个人员信息表，再比如说薪资核算的管理对象是每个人的薪资，所以多一个薪资存档表。业务表单是围绕着基础信息来的。查询报表其中一个静态查询也是围绕着基础信息来。 3、查询报表 查询报表这块，我划分为快速查询和报表分析两个部分。快速查询就是围绕基础信息和业务表单做一些快速查询，用查询模板。报表分析这块，就是要做一些比较复杂的分析了，我按时间划分为月度、季度和年度，比如我们人力资源的人事报表，还比如店铺人力成本分析报表等，这个基本是根据管理需要来。这个还没动过，但报表模板还是做过几个，花点心思，我觉得还是能做出一些比较丰富的报表来。这些报表做出来后，我觉得是要保存存档的，这个还没想到方案，是导入成EXCEL格式（但听说图表不能导出）？还是导出一些想要的数据，然后再在EXCEL里加工？ 4、操作导航 我原来是只有一个操作导航的，而且放在了“直营人事系统”这个目录下。但前段时间看了一些workday、dayHR等人力资源系统的介绍，里面针对特定岗位会设置一些导航页面。受这个思路启发，我把操作导航提了出来，然后这个系统里有店铺、区管和人事三个操作层次，所以就规划了三个导航页面。这个暂时只是个规划，还没有做，我是想做好看好用些的。尽量让操作人员不用去左侧导航栏去翻，直接通过导航页面就能完成大部分操作。现在看，这么放着，确实比原来清晰很多。因为原来点“直营人事系统”这个按钮，右侧是出现导航栏，左侧又是目录栏，系统设计的人没什么，但会给用的人带来一些信息干扰。 |
+1
0
| 说下一个主题“UI设计”之前，插一个话题，就是这样一个系统能为零售连锁体系的人事管理带来哪些用处。我想分几点来说明： 1、人员信息的实时更新。原来我们的入调离，使用传统的纸质申请、审批，然后快递或者传真给我们。这个是有时间滞后的，你可能认为这个滞后顶多也就几天吧。但实际情况是，你的店铺网点一多，真有隔了两三个星期，到月底算工资的时候，资料才上来，我们那个时候才知道的。人员信息更新还是一回事，最麻烦的是，人员离职了，我们还给人挂了社保，这个费用就得我们自己承担了，这事情发生了好几次。这个功能，其实很多系统都能实现，所以也没啥好深入说的。 2、薪资核算。这个是重点，算一家店的薪资容易，但要算一两百家店铺的薪资真得是一个辛苦活，特别算工资都是集中在一两个星期。我们的工资核算是从1号开始，早的10号发，晚的最迟不能超过15号。主要工作，一是审核（具体算是由店铺完成，如果算是我们，那会很惨）、二是做各种汇总表。这个工作，一个人到60家左右，就偶要加班了，到80家的时候，就常要加班，到100家，估计一个人就顶不住。所以，用这个系统，单纯数据审核汇总来说，无论多少家，基本上一个人就能搞得定。另外，店铺核算也省了很多事情，也不会老犯错，她们少犯错，又间接促成我们省事。这几天又发生一个事情，就是店铺员工有个年终奖，这个年终奖是和全年销售达标率挂钩的。大家想象一下吧！！！怎么样？能体会到我们的痛苦了不？知道我们是怎么做得吧，找出每个月做的表，把每张表里面的信息复制出来，还要加上几列核算时候有的信息，然后再做筛选汇总。明年我们要到两百家店，如果还按原来的方式干，薪资核算这块，就得到三人，还痛苦。如果一个人干这活，还轻松，“那是很好的”。哦，一个人的年薪大概是五六万左右。 |
+1
0
| 木才兄弟能分享自己的成果值得赞赏，设计思路非常清晰，模块分类也很合理。值得一提的是在设计中能不断修正自己的思路，这是求真务实和不断提升的精神，值得大家学习的。点赞！ |
+1
0
