突然间想把这段时间做的这个系统做一个总结，也算是分享吧！开始之前，我觉得特别想感谢一些人，这些人在我学习云表并制作这个系统过程中，提供了非常大的帮助。排前两位的，是张晨和乐乐，张晨在我入门的那段时间，真算是手把手教呀，所以尊称他为老师，乐乐在系统原理方面给了我醍醐灌顶般的帮助，再就是jolin，后期有啥问题的，我都会直接@她，这样获得解答的效率最高，还有就是恐龙爷爷、湖边漫步、CC这些人，在讨论问题的过程中让我收获很多。 另外说一说总结的方式，既然是总结，所以就不仅仅是展示一下具体表单，重点还在于回顾我的设计出发点-为什么这么整、在制作过程碰到的问题及解决方法或思路、以及对云表的建议。所以这个贴会不断更新，楼数会比较多，分享进度可能也会比较慢。 好了，现在开始正题。。。 零售连锁的人事薪资系统，有两块业务，一是需要解决人员的入调离职问题，二是每家店的薪资填报核算和汇总问题： 第一个问题，用云表的业务公式很好解决，这让我想起六七年前用勤哲做这个事情的时候，那是相当痛苦，那个时候的表间公式来解决这个问题会非常的绕，到最后还是放弃，不过也因为那个时候玩这类的系统，打下了一些基础，更关键的是勤哲的学习手册非常完善，我是认认真真的看过很多遍，这让我学习云表的时候上手比较快。（题外话，云表的学习手册真得真得需要好好完善，这需要有专门的人员或小团队来编写和维护这个文档） 第二个问题，薪资核算模块是这个系统的难点。如果有接触过零售系统的同学就会知道，终端销售人员的薪资结构很复杂，有提成（通常会和销售额、个人达标率、店铺达标率、公私佣类型、职级挂钩）、有各种奖项（团队达标奖、个人达标奖、最高销售业务奖等）、有各种补贴、最麻烦的是调店和支援情况（人员会在不同店铺间调来调去）、然后还有各种汇总表（一家店铺的主体可能是分公司，也可能是不同的个体户，每一个主体在财务上都要分别核算。还有其他很多汇总表，比如区域核算人力成本等等等）。看吧，是满复杂呀。今天我能把这些问题解决的七七八八，用云表做成一个非常自动化的系统，我是非常非常自豪的，也非常非常意外云表的易用性。如果是六七年前的勤哲，我是碰都不敢碰这块业务的。（题外话，我虽然经常玩这类型应用，但我没有编程基础，一直都在服装行业做人力资源或销售管理。所以你会理解我的意外喜和自豪感） 先开这个头吧，还有正事要做，慢慢来！ |
+11
最近谁赞过
29 条回帖
本帖最后由 木才 于 2015-12-18 17:10 编辑 
一、系统规划 先从系统规划说起。总结这段时间的经验和云表特点，像这样的小系统，我会划分为：参数设置、基础信息/档案、业务表单、查询报表和操作导航五个部分。其中有几点值得说一说： 1、参数设置 我原来所有参数设置是放到一个文件夹中的，但后来整理的时候发现，有些参数相对固定，你设置一次以后，相当长一段时间，比如说半年一年的都不需要动，比如说这套系统里的一些薪资政策的设置（如何提成，几个相对固定的奖金）、每月计薪天数等，一般这部分参数设置的权限会限定为系统管理员。还有些参数会经常性变化，需要日常维护，比如说新增店铺和店铺主体等，这部分数据是需要指定人员来维护的。 2、基础信息或者叫基础档案 我原来基础信息里只有员工档案，那个月度薪资存档是后来加进来的。为什么要加进来呢？其中有两个原因，一是我业务表单里的薪资核算表的布局比较散，信息量也很大，而大家都知道，人事这个环节核算完薪资表后，还是需要提交给财务的，所以当时我就想做一个中间表，按财务要求的规范和信息来做，用业务公式获取核算表的数据。这个原因，当时是主要原因，但现在回顾来看，我把它列为次要原因。最主要的原因，是下面这个。在薪资核算表里，需要从员工档案表里带出员工信息，其中一些员工信息，是作为各类薪资汇总表的依据，比如所这个员工的社保是在哪个主体里买的，要命的是，这个信息是在变的。万一我核算的时候是A，后来变成了B，我又去刷新了一个薪资核算表，我在做汇总的时候，就变成了B，汇总表和核算表就对应不上了。虽然这是非常例外的情况，但为了防止这种万一，我想到了要一个中间表来存放我进行核算那个时刻的所有状态，这个中间表的数据是相对固定的。我所有汇总表的依据，也是从这个中间表来做。但说了这么多，下面这个信息才是重点，是重点，是重点，就是乐乐说过的“任何一个系统都会有管理对象”，而我认为这个管理对象就适合在基础信息里体现，比如说人事变动的管理对象是人，所以有一个人员信息表，再比如说薪资核算的管理对象是每个人的薪资，所以多一个薪资存档表。业务表单是围绕着基础信息来的。查询报表其中一个静态查询也是围绕着基础信息来。 3、查询报表 查询报表这块，我划分为快速查询和报表分析两个部分。快速查询就是围绕基础信息和业务表单做一些快速查询，用查询模板。报表分析这块，就是要做一些比较复杂的分析了，我按时间划分为月度、季度和年度，比如我们人力资源的人事报表，还比如店铺人力成本分析报表等，这个基本是根据管理需要来。这个还没动过，但报表模板还是做过几个，花点心思，我觉得还是能做出一些比较丰富的报表来。这些报表做出来后，我觉得是要保存存档的，这个还没想到方案，是导入成EXCEL格式（但听说图表不能导出）？还是导出一些想要的数据，然后再在EXCEL里加工？ 4、操作导航 我原来是只有一个操作导航的，而且放在了“直营人事系统”这个目录下。但前段时间看了一些workday、dayHR等人力资源系统的介绍，里面针对特定岗位会设置一些导航页面。受这个思路启发，我把操作导航提了出来，然后这个系统里有店铺、区管和人事三个操作层次，所以就规划了三个导航页面。这个暂时只是个规划，还没有做，我是想做好看好用些的。尽量让操作人员不用去左侧导航栏去翻，直接通过导航页面就能完成大部分操作。现在看，这么放着，确实比原来清晰很多。因为原来点“直营人事系统”这个按钮，右侧是出现导航栏，左侧又是目录栏，系统设计的人没什么，但会给用的人带来一些信息干扰。 |
+10
| 说下一个主题“UI设计”之前，插一个话题，就是这样一个系统能为零售连锁体系的人事管理带来哪些用处。我想分几点来说明： 1、人员信息的实时更新。原来我们的入调离，使用传统的纸质申请、审批，然后快递或者传真给我们。这个是有时间滞后的，你可能认为这个滞后顶多也就几天吧。但实际情况是，你的店铺网点一多，真有隔了两三个星期，到月底算工资的时候，资料才上来，我们那个时候才知道的。人员信息更新还是一回事，最麻烦的是，人员离职了，我们还给人挂了社保，这个费用就得我们自己承担了，这事情发生了好几次。这个功能，其实很多系统都能实现，所以也没啥好深入说的。 2、薪资核算。这个是重点，算一家店的薪资容易，但要算一两百家店铺的薪资真得是一个辛苦活，特别算工资都是集中在一两个星期。我们的工资核算是从1号开始，早的10号发，晚的最迟不能超过15号。主要工作，一是审核（具体算是由店铺完成，如果算是我们，那会很惨）、二是做各种汇总表。这个工作，一个人到60家左右，就偶要加班了，到80家的时候，就常要加班，到100家，估计一个人就顶不住。所以，用这个系统，单纯数据审核汇总来说，无论多少家，基本上一个人就能搞得定。另外，店铺核算也省了很多事情，也不会老犯错，她们少犯错，又间接促成我们省事。这几天又发生一个事情，就是店铺员工有个年终奖，这个年终奖是和全年销售达标率挂钩的。大家想象一下吧！！！怎么样？能体会到我们的痛苦了不？知道我们是怎么做得吧，找出每个月做的表，把每张表里面的信息复制出来，还要加上几列核算时候有的信息，然后再做筛选汇总。明年我们要到两百家店，如果还按原来的方式干，薪资核算这块，就得到三人，还痛苦。如果一个人干这活，还轻松，“那是很好的”。哦，一个人的年薪大概是五六万左右。 |
+10
| 本帖最后由 木才 于 2015-12-26 11:24 编辑 二、UI设计（1） 信息量比较大，分几楼
和workday、dayHR这些最近出来的人力资源信息系统相比，在UI视觉的体验上，云表自然是没法比了。但我觉得，UI设计除了美观之外，用户的易用性是更重要的一个方面，在这方面，云表还是提供了很多定义，也看到了一些案例。因为十几年前做过几年的网页设计，所以这方面还是能够表达一些观点。尽管现在用云表做出的东西不多，但大概的方向我想还是有的。 1、登陆界面/关于界面：这个很简单，文档里有教程。实际上就是改登陆页面的背景，只是这个背景要预设登陆框位置（用户名录入框、密码录入框、是否记住密码、登陆），然后将云表系统里的这四个控件叠加上去。所以想象为两层，底层是背景图片，顶层是云表控件，就容易明白了。如果要做整个整个页面的大背景，文档里推荐的图片大小是“高度：944，宽度：1767”，没试过。但淘宝店铺的全幅海报，宽度是1860，这个以后再试试。
2、导航界面：我觉得这个非常非常重要。很多工作，从单个环节来看，操作都是比较单一简单的。对于一开始接触系统的用户来说，他们不会像系统设计者一样，具备探索系统的精神和动力。他们只想知道，这个系统我要操作什么？如何操作？你不要让我到处去找、去查、去理解整个系统的逻辑关系，简简单单告诉我怎么做就可以。所以这个导航界面，我觉得是非常重要的。即在美观上有要求，在易用性上也需要好好思考。导航界面我也还没做出个成品，所以就不展开说。等到时候做出来了，再来补楼。但有一个观点是需要提出的，即导航界面是放系统架构的逻辑图，还是针对用户做操作指引？这个区别还是非常大的，你的选择决定了这个导航页面对用户的行为，是真的通过导航页面来做日常操作？还是登陆系统的第一件事就是把导航页面关闭？ 3、总表界面：总表显示哪些数据？先后顺序？列宽？行颜色？都是值得好好斟酌一下的，这会影响用户对系统的理解和对信息的阅读。有几点值得说一说： （1）设置列宽是件比较繁索的事情，我的经验是你先定好一个自己的列宽标准，比如说两个字的多宽、三个字的多宽、四个字的多宽、身份证多宽……，然后在数据表管理的宽度里直接改数字，这样效率会快一点。
（2）状态字段的顺序现在是没办法调的，根据经验来看，应该是根据建立这个字段的时间顺序来排列。比如说表格字段你先建立了A、B、C，然后增加了审核和审批两个状态字段，这两个审核和审批字段就在后面了，顺序为A、B、C、审核、审批。ABC可以调序，审核审批不行。如果你后面修改了表单，增加了D字段，那就只能A、B、C、审核、审批、D了，总表呈现上很不好看（我是狮子座，但对设计这事，处女座情结比较重），这种事情是没办法容忍的。怎么办呢？记得是时间先后顺序！所以，先把审核和审批两个状态字段删了，然后再增加。删除的时候记得两个地方要备份，一是状态设计的业务公式，先复制到“锁定”字段上，重新增加状态后，再粘贴出来；二是状态字段的定义也可以先复制到EXCEL表格上，新建状态的时候再粘贴过来，省事。要状态字段排到最前面？我也想，但我是不敢做这事，你得删删减减多少哇～～～所以，强烈要求乐乐增加状态字段排序功能！！！
（3）行颜色，这个在很多软件里都是一个非常有用的功能，云表也提供了丰富的设置。但建议云表也能够像其它软件一样，在总表里设置一个备注栏，我们可以定义一些说明，比如说“黄色等待区域审核”、“粉色等待登帐”之类的。另外，别说我没告诉大家，设置格式颜色的判断条件，只能用英文的true\false，不能用“常量.是”这样的。这事情，我是来回找了一个多小时问题，没找着，问了jolin才知道的！
（4）总表有状态字段，这个状态字段在总表状态总击是有效的、有效的、有效的，而且不能屏蔽。这绝对算是奇葩设计了（乐乐别骂我呀），很多人已经提出这个问题了，希望下个修改版本能改（但听张晨说这事提了几年了，汗）。为什么大家都建议改呢，一从设计上看，很多状态字段会设置填表公式，在总表点状态，这个填表公式是不执行的；二你在总表可以快速审核，不是鼓励人偷懒不看表审核吗？现在我是比较纠结的，要不要和用户说，审核不能在总表点呢？告诉他，不是等于和他说你有这个方法可以快捷操作？不告诉他，万一他自己发现了呢？你们说，要告诉他们呢？还是不告诉呢？还是告诉呢？所以这个状态字段，还是快快设置一下屏蔽开关吧，乐乐，听到人民的呼声了吗？（估计绝大多数人会关了） |
+10
| 本帖最后由 木才 于 2015-12-26 12:08 编辑 UI设计（2） 4、表单界面。这个要重点说一下这个。话说，这两天明细表分离已经开放出来了，看了乐乐展示的一些应用，还是很有想象空间的。张晨说，业务公式加明细表分离，算是彻底将云表和同类软件拉开距离了。但我觉得数据接口和填表公式也挺猛的呀？！ 按钮图1
按钮图2
（1）先说按钮控件。这个是决定“取何物”和“何处安放”的问题。图一是我现在的做法，图二是我原来的做法，而且我现在还是认为图二的方式更符合用户习惯。说说我的几个观点吧： 第一，不需要的按钮绝不出现。云表上的控件按钮还是比较丰富的，所以一定要有所选择，不能一鼓脑儿加上去。比如说那个针对明细表的插入行和删除行，因为云表明细表的行增加是跟着最后一行自动增加的，所以有没有这个行增减按钮的作用不大，我的选择就是能不要就尽量不要。减少按钮，就是减少用户的使用成本和理解障碍。 第二，按钮有两个地方可以放，一个是表头的工具栏、第二是单元格，其中状态按钮自动出现在工具栏上，如果你设置了工具栏按钮，则自动跟在后面。我原来设计的思路是放弃工具栏，用单元格按钮。因为简单的系统，大多数只要进行“保存”和“退出”两个操作，用单元格按钮非常符合WEB应用的使用习惯，又很干净。但后来我的系统复杂了些，操作按钮多了，又决定使用状态来代替流程（为什么这么选择我会另外盖个楼来说，最开始接触云表的时候我是很想要流程这个功能的，但现在算是比较彻底的放弃了）。这个时候，我就只能在表头工具栏来组织按钮了。为了区分，我划分为“常用操作”和“流程跟进”两个部分，并用工具栏里的自定义按钮做了一下区隔。这里说一下，工具栏的定义功能还是弱了些，希望乐乐在这块能够列入改版计划，这个对软件的易用性、理解表达和专业度的影响还是蛮大的。 第三，就是表单锁定后，单元格按钮仍然可以执行的问题。为了这事，我曾经放弃一个单元格按钮，用状态按钮来代替。虽说按钮公式执行后，也没办法保存，只是看看，但这还是让人不舒服。比如说，填表的人用按钮公式执行自动计算，审核的人发现有个数据有问题，直接改了。审核后表单锁定，但有一天你又打开表单，点了一下自动计算，发现有个数据不对呀。咋整？完美主义者是不能容忍这样的事情的。前几天群里面也有人说起，jolin说，因为有些设计是即使表单锁定，也希望能够执行按钮公式。如果不希望锁定后执行的话，可以设置一个按钮执行的条件。比如这样：
（2）再说一下表单设计。话说我是十几年前做网页的，那是啥年代？是用<table><tr><td></td></tr></table>来定义的时代呀。所以在我眼里，用云表进行复杂的美工是完全没问题的，只是用户是否需要、是否能接受的一个问题。改天定义一个漂（sao）亮（bao）的页面，测试一下云表的展现速度怎么样。有几个小技巧说说： ①已经定义了基本数据项的单元格，在表单页面是可以随意移动的，鼠标放在单元格左上角呈箭头十字的时候就可以移了。哇cao，这件事情我是用了一两个月云表后才知道的，知道我原来是怎么移的吗？在数据表管理里面设置单元格位置（这是多年前qinzhe的玩法），所以一直以为云表也是这么移。哇cao，新手们，别说我没告诉你！ ②明细表位置怎么移？我现在还是在数据表管理里改单元格位置了，别告诉我也有快捷方法哇～～～ ③数据项单元格要合并其它单元格，要先将数据项单元格移到最右上角的位置 ④经常要用到隐藏的明细列吧！我开始还会去修改一下字体颜色和背景单元格颜色一致。后来才发现，这（chi）是（bao）完（cheng）全（zhe）没（mei）必（shi）要（zhao）的（shi）。直接将列宽设置为1就可以了。核查时，再把列宽拉开就可以
⑤有多个明细表时，如何避免老是去调整合并单元格？碰到这种复杂表，一开始设计的时候，先统一将所有列宽调到20左右，然后再进行表单设计，合并是需要的，但可以避免你后期去插入列；
⑥如果明细表左侧或右侧设计了装饰列，如何避免明细表自动增加行时，左右侧装饰列断行？装饰列再往下多合并一行，而这行不要设置为数据行
（3）表单界面这条道上，我还是一个初学者，实践尝试的也很少，说多，莫怪！而且现在明细表分离又出来了，都说是一个变革性的功能。乐乐，如果云表能出啥皮肤主题切换之类的功能，那真得是高大上鸟～～～ |
+10
| UI设计（3） 5、使用标签页还是对话框？这个就像网页设计里打开页面方式是选择_self还是_ blank一样纠结呀！我原来的想法是，总表是用标签页表示的，那一张张的表单我就全部用对话框，这样给用户带来明显的区分感和层次感。但做到薪资核算表的时候，表单比较大，已经快到整个显示框大小了，这个大的表单悬浮的话，一是感观不好，二是如果侧边导航栏没关的话，就会顶住了，三是要滑动滚动条了。小表单的时候，一切都是那么美好，大表单的时候，又不美好了。所以，最后还是全部统一用标签页了，用户一开始就认为系统的页面逻辑是这样，也就习惯了，呵呵。另外，曾经有提出一个问题：打开标签页，是在当前页面打开，还是新的标签页打开？我原来是强烈建议在当前页面打开的，因为在新标签页打开的话，用户使用，还是会去这点点，那点点的，可能一下子会打开很多标签页，会显得乱。但后来注意到另外一个事情，就是打开过的标签页，你再在导航栏里点开时，是直接打开原来打开过的页面，这意味着不需要重新等待打开。各有利蔽，所以也就不那么强烈了。 6、最后说一下在易用性方面，我的几个思考 （1）让用户操作成为一个自然的逻辑过程，不要让人绕弯弯 （2）减少信息干扰，不需要出现的信息一定不要出现 （3）信息表达层现的逻辑、层次、类别，一要清晰，二要简单 |
+10
三、为什么放弃工作流 这段时间太忙了，开了帖断太久又不太好。正好看到群里有人在讨论流程管控，所以插空说一下流程管控。 首先要说明的是，我放弃的是工作流这个系统功能，而不是放弃流程管控。最开始接触工作流这个功能，是在通达OA，后来接触的OA系统都有这么个功能。接着开始接触类ERP的软件，比较勤哲之类的。当时就想，如果整个业务系统能用工作流这样的东西来定义框住，该是多么理想的事情。我估计很多管理者或者老板都会有这个的思维，谁应该干什么、什么时候干，都规定好，企业管理不是变得很简单了吗？科学管理的思维就是这样。 但我后来做管理咨询的时候，开始接触服装这个行业的很多ERP软件（因为当时做服装商品管控的项目），像丽晶、百胜、志华，发现这些软件通通没有工作流这个玩意。不知道有没有人关注到这个事实，工作流是OA系统玩的东西，ERP系统里都不玩这个。为什么？ 刚接触云表的时候，我还是很执意要玩转工作流的，因为自己做了公司的供应链流程，发现执行过程中太随意，所以想有个固定的东西框一下，当时还有在群里问过这事情，张晨回答说，他现在都不用工作流，用业务公式和状态就把这事情做好了。于是，我循着这个思路去做，开始发现这样做的时候，思路变得更加清晰，调整也更加灵活。但我还是在想一个问题，ERP软件为什么不玩工作流？回顾我们自己实际的业务流程，我发现一个事情，从整个业务流程来看，业务是相对稳定的，但业务流转却非常灵活，经常会变。也就是说，开展这个业务，要做哪些事情是相对灵活的，但由谁来做、谁做完交给谁、权限怎么分配这些事情是经常变得。要做的那些事情，在系统里就表现为表单，而由谁来做等等，就有人想用工作流来固定。但如果你一旦这么做，绝大多数情况下，你的系统会被业务执行玩死。因为这个变化太快了。我想可能只有一种情况适合，就是非常稳定的那种流水线。但有这样业务特征的模块，毕竟是少数。 那么流程管理怎么做呢？首先你在做系统设计的时候，设计一张张的业务表单，定义一项项基础数据，再设计表单之间的业务逻辑（业务公式），其实就已经在设计业务逻辑了，这是一个大的业务流转。也就是说，你不用工作流，你实际上已经设计了大范围的业务流程。剩下的业务流转，就是单个表单范围内的事情，而单个表单范围内的事情，用状态设置+总表格式，我觉得已经能够很好的解决。或者换个说法，要做什么事情，这个事情与事情之间的关联，你在设计系统的时候就已经定义了，这个是相对稳定的。而事情与人的关系，就把这放在单个表单里，用权限和状态来完成，而不是用工作流。你这工作流又定义事情，又定义人，会和原来的体系设计相混淆，会让人痛苦的。 所以，今天讨论的时候，延着张晨的思路，我回了一句“填表公式+业务公式+内部邮箱+内部邮箱提示+有更多样式定义功能的状态设置”，就是流程。工作流，我已经放弃了，甚至希望乐乐也不要将过多精力放在工作流上，而是把内部邮箱整出来，其中内部邮箱划分为两部分，一部分是普通的工作信息沟通，另一部分是流程作业提示（用业务公式定义邮箱内容，邮箱内容有直接打开相应的表单链接）。另外，状态设置和状态栏（填表单和总表）的样式设置有更多的定义功能。那就完美了。 |
+10
