突然间想把这段时间做的这个系统做一个总结,也算是分享吧!开始之前,我觉得特别想感谢一些人,这些人在我学习云表并制作这个系统过程中,提供了非常大的帮助。排前两位的,是张晨和乐乐,张晨在我入门的那段时间,真算是手把手教呀,所以尊称他为老师,乐乐在系统原理方面给了我醍醐灌顶般的帮助,再就是jolin,后期有啥问题的,我都会直接@她,这样获得解答的效率最高,还有就是恐龙爷爷、湖边漫步、CC这些人,在讨论问题的过程中让我收获很多。

另外说一说总结的方式,既然是总结,所以就不仅仅是展示一下具体表单,重点还在于回顾我的设计出发点-为什么这么整、在制作过程碰到的问题及解决方法或思路、以及对云表的建议。所以这个贴会不断更新,楼数会比较多,分享进度可能也会比较慢。

好了,现在开始正题。。。

零售连锁的人事薪资系统,有两块业务,一是需要解决人员的入调离职问题,二是每家店的薪资填报核算和汇总问题:

第一个问题,用云表的业务公式很好解决,这让我想起六七年前用勤哲做这个事情的时候,那是相当痛苦,那个时候的表间公式来解决这个问题会非常的绕,到最后还是放弃,不过也因为那个时候玩这类的系统,打下了一些基础,更关键的是勤哲的学习手册非常完善,我是认认真真的看过很多遍,这让我学习云表的时候上手比较快。(题外话,云表的学习手册真得真得需要好好完善,这需要有专门的人员或小团队来编写和维护这个文档

第二个问题,薪资核算模块是这个系统的难点。如果有接触过零售系统的同学就会知道,终端销售人员的薪资结构很复杂,有提成(通常会和销售额、个人达标率、店铺达标率、公私佣类型、职级挂钩)、有各种奖项(团队达标奖、个人达标奖、最高销售业务奖等)、有各种补贴、最麻烦的是调店和支援情况(人员会在不同店铺间调来调去)、然后还有各种汇总表(一家店铺的主体可能是分公司,也可能是不同的个体户,每一个主体在财务上都要分别核算。还有其他很多汇总表,比如区域核算人力成本等等等)。看吧,是满复杂呀。今天我能把这些问题解决的七七八八,用云表做成一个非常自动化的系统,我是非常非常自豪的,也非常非常意外云表的易用性。如果是六七年前的勤哲,我是碰都不敢碰这块业务的。(题外话,我虽然经常玩这类型应用,但我没有编程基础,一直都在服装行业做人力资源或销售管理。所以你会理解我的意外喜和自豪感)

先开这个头吧,还有正事要做,慢慢来!


1人收藏
26 条回帖
木才云苗2015-12-18 13:45:34
本帖最后由 木才 于 2015-12-18 17:10 编辑

1系统规划.jpg


一、系统规划
先从系统规划说起。总结这段时间的经验和云表特点,像这样的小系统,我会划分为:参数设置、基础信息/档案、业务表单、查询报表和操作导航五个部分。其中有几点值得说一说:

1、参数设置
我原来所有参数设置是放到一个文件夹中的,但后来整理的时候发现,有些参数相对固定,你设置一次以后,相当长一段时间,比如说半年一年的都不需要动,比如说这套系统里的一些薪资政策的设置(如何提成,几个相对固定的奖金)、每月计薪天数等,一般这部分参数设置的权限会限定为系统管理员。还有些参数会经常性变化,需要日常维护,比如说新增店铺和店铺主体等,这部分数据是需要指定人员来维护的。

2、基础信息或者叫基础档案
我原来基础信息里只有员工档案,那个月度薪资存档是后来加进来的。为什么要加进来呢?其中有两个原因,一是我业务表单里的薪资核算表的布局比较散,信息量也很大,而大家都知道,人事这个环节核算完薪资表后,还是需要提交给财务的,所以当时我就想做一个中间表,按财务要求的规范和信息来做,用业务公式获取核算表的数据。这个原因,当时是主要原因,但现在回顾来看,我把它列为次要原因。最主要的原因,是下面这个。在薪资核算表里,需要从员工档案表里带出员工信息,其中一些员工信息,是作为各类薪资汇总表的依据,比如所这个员工的社保是在哪个主体里买的,要命的是,这个信息是在变的。万一我核算的时候是A,后来变成了B,我又去刷新了一个薪资核算表,我在做汇总的时候,就变成了B,汇总表和核算表就对应不上了。虽然这是非常例外的情况,但为了防止这种万一,我想到了要一个中间表来存放我进行核算那个时刻的所有状态,这个中间表的数据是相对固定的。我所有汇总表的依据,也是从这个中间表来做。但说了这么多,下面这个信息才是重点,是重点,是重点,就是乐乐说过的“任何一个系统都会有管理对象”,而我认为这个管理对象就适合在基础信息里体现,比如说人事变动的管理对象是人,所以有一个人员信息表,再比如说薪资核算的管理对象是每个人的薪资,所以多一个薪资存档表。业务表单是围绕着基础信息来的。查询报表其中一个静态查询也是围绕着基础信息来。

3、查询报表
查询报表这块,我划分为快速查询和报表分析两个部分。快速查询就是围绕基础信息和业务表单做一些快速查询,用查询模板。报表分析这块,就是要做一些比较复杂的分析了,我按时间划分为月度、季度和年度,比如我们人力资源的人事报表,还比如店铺人力成本分析报表等,这个基本是根据管理需要来。这个还没动过,但报表模板还是做过几个,花点心思,我觉得还是能做出一些比较丰富的报表来。这些报表做出来后,我觉得是要保存存档的,这个还没想到方案,是导入成EXCEL格式(但听说图表不能导出)?还是导出一些想要的数据,然后再在EXCEL里加工?

4、操作导航
我原来是只有一个操作导航的,而且放在了“直营人事系统”这个目录下。但前段时间看了一些workday、dayHR等人力资源系统的介绍,里面针对特定岗位会设置一些导航页面。受这个思路启发,我把操作导航提了出来,然后这个系统里有店铺、区管和人事三个操作层次,所以就规划了三个导航页面。这个暂时只是个规划,还没有做,我是想做好看好用些的。尽量让操作人员不用去左侧导航栏去翻,直接通过导航页面就能完成大部分操作。现在看,这么放着,确实比原来清晰很多。因为原来点“直营人事系统”这个按钮,右侧是出现导航栏,左侧又是目录栏,系统设计的人没什么,但会给用的人带来一些信息干扰。
乐乐云道2015-12-18 16:19:11
先抢个板凳,坐等楼主继续
木才云苗2015-12-18 17:41:30
说下一个主题“UI设计”之前,插一个话题,就是这样一个系统能为零售连锁体系的人事管理带来哪些用处。我想分几点来说明:

1、人员信息的实时更新。原来我们的入调离,使用传统的纸质申请、审批,然后快递或者传真给我们。这个是有时间滞后的,你可能认为这个滞后顶多也就几天吧。但实际情况是,你的店铺网点一多,真有隔了两三个星期,到月底算工资的时候,资料才上来,我们那个时候才知道的。人员信息更新还是一回事,最麻烦的是,人员离职了,我们还给人挂了社保,这个费用就得我们自己承担了,这事情发生了好几次。这个功能,其实很多系统都能实现,所以也没啥好深入说的。

2、薪资核算。这个是重点,算一家店的薪资容易,但要算一两百家店铺的薪资真得是一个辛苦活,特别算工资都是集中在一两个星期。我们的工资核算是从1号开始,早的10号发,晚的最迟不能超过15号。主要工作,一是审核(具体算是由店铺完成,如果算是我们,那会很惨)、二是做各种汇总表。这个工作,一个人到60家左右,就偶要加班了,到80家的时候,就常要加班,到100家,估计一个人就顶不住。所以,用这个系统,单纯数据审核汇总来说,无论多少家,基本上一个人就能搞得定。另外,店铺核算也省了很多事情,也不会老犯错,她们少犯错,又间接促成我们省事。这几天又发生一个事情,就是店铺员工有个年终奖,这个年终奖是和全年销售达标率挂钩的。大家想象一下吧!!!怎么样?能体会到我们的痛苦了不?知道我们是怎么做得吧,找出每个月做的表,把每张表里面的信息复制出来,还要加上几列核算时候有的信息,然后再做筛选汇总。明年我们要到两百家店,如果还按原来的方式干,薪资核算这块,就得到三人,还痛苦。如果一个人干这活,还轻松,“那是很好的”。哦,一个人的年薪大概是五六万左右。
图客云苗2015-12-18 21:24:22
搬个凳子坐前排,听得清楚些。
乐乐云道2015-12-19 10:04:03
我断定此贴必火,有演绎成云表开发长篇小说的节奏
CHINACYN云粉2015-12-19 10:15:38
太感谢楼主啦,先学习下。
syeplay云苗2015-12-19 10:27:49
坐等更新
shanghaijg版主2015-12-20 14:30:13
   木才兄弟能分享自己的成果值得赞赏,设计思路非常清晰,模块分类也很合理。值得一提的是在设计中能不断修正自己的思路,这是求真务实和不断提升的精神,值得大家学习的。点赞!
HAHA云苗2015-12-21 18:06:31
占个楼等更新
123下一页
需要登陆后才可进行回复 登录