你有遇过那种大家公认的计算机高手、软件达人、或 Excel 小天才吗(或者你自己就是)?
可能从没读过信息、资管相关科系,大学念的可能就是文组,但新软件都学得好快,或许对 IFTTT、Notion、Trello、ClickUp 这类工具如数家珍,也或许是任何事情都能做成超精美 Google Sheets、Excel 公式超强、总是可以把数据统整得井井有条……
这类“信息小天才”,在职场上很吃香,我们会想像这份能力,能为他既有的工作加分。不过,如果只是软件产品爱好者、Excel 重度用户,感觉上比较像能帮我解决表格问题的“强者我同事”,要直接大变身,变成某家公司的专职 IT、MIS、工程师……好像还是有点落差。
不过,我们最近就听到了这样的故事:一个不会写程序、对计算机工具很有兴趣、刚毕业几年的年轻人,遇上 Ragic 这样的 No Code 开发工具,进而变成公司专职 IT ,一肩扛起公司系统升级任务的故事。来看看吧!
虽然读传播科系,但 Bill 很早就发现自己对于信息管理很感兴趣,在大学时期修过几堂课,有自己的一套信息处理概念、逻辑,要在 Google 电子表格、Excel 上设计出各种复杂的公式也难不倒他。
Bill 在毕业前负责系上毕筹会的财务计算,利用他擅长的 Google 电子表格设计公式、串接表单,让对帐的过程能够更顺利。不过有个 Google 没法解决的问题,有点困扰:很多时候毕筹会讨论好预算,确定要支出款项的时候,会有原先默不出声的同学们退出来说“我不同意支出这笔钱”。
这也是他认识 Ragic 的契机——Ragic 是市面上少数免费版就具备签核功能、轻量使用也很轻松的表单工具。用了 Ragic 每一笔支出在表单上都必须经由同学们主动单击下同意或拒绝签核,系统上也会有明文记录,自然就能大大减少后续可能发生的争议。
Bill 在毕业之后找到了一份与学历专业相关的工作——为公家机关编写文案与图卡设计的社群企划网编。
机关内部会有一套帖子审查的 SOP 必须遵循,举例来说:为了确保政策宣导信息传递的正确性,完成的图文都须经打印件方式上呈。在运行的过程中,上呈的流程跟关卡可能会异动,有时一篇帖子最多需要经过七个人的审核。
为了配合单元的打印件格式,Bill 会从自己习惯使用的 Google 电子表格把帖子内容拷贝、再贴到指定的标准 Word 审查表格式,稍加排版再打印出来上呈。但凡内容需要修改,也就必须重复一次“在 Google 电子表格修改帖子 → 贴到 Word 排版”的过程,再重新打印输出来上呈。
随着修改的可能性增加,一则帖子花费往返查找数据、拷贝贴上的时间也越来越多,他想到了 Ragic 的归并打印可以解决他的烦恼:“假如今天帖子要修改,就到 Ragic 上面编辑,改完之后就直接引出归并打印,就不需要再做多余的步骤。”省去了慢慢在 Google 电子表格上找数据,再反覆手动贴到 Word 的过程。
某次,专案中加入两位外聘的专业社群顾问,也需要参与审查的签核流程。但是,外聘顾问并不是公司内部的人,该如何将他们的意见、签名放在打印件文档上?实际上有很多困难需要解决:“要邮寄?或亲自送过去?用 PDF 签名对一般用户而言又太过麻烦,而且又有两位顾问,签名该怎么集成在同一份打印件上?”
这个时候,Ragic 的签核功能就派上用场了。只要将顾问们的 E-mail 设为签核关卡、发起签核,寄送写好的帖子数据给他们,并以邮箱打开签准,就能填写意见、签名。表单上只要加入签核公式字段,并套用归并打印,就能在打印件文档上呈现来自外部顾问的意见与签字了。
Bill 说:“我无法改变单元既有的打印件需求、很难让签核流程全部电子化,但是我能让 Ragic 符合既有的 SOP 标准流程,让我自己工作上方便。”
在 Ragic 修改设计并不是什么麻烦的大工程,只要简单拖拉字段、单击下保存设计就能随心所欲调整表单,就算常常更改流程也不怕:“毕竟标案内容的异动性与弹性都很高、需要留意的事项也会越来越多,该如何达成单元的需求、又要确保不搞砸,就一定要有一个好的工具来协助自己。”
搭配 Ragic 改善工作流程后,只要写完帖子就可以一秒开始送审,不需要再把时间浪费在找数据、改帖子跟排版:“节省下来的时间就可以去处理更有意义的事了。”
结束社群网编的工作之后,Bill 来到了一间成立了 30 年、客制化生产团体服的公司——衣的艺术。
Bill 被编入公司的信息部,而他的职责就是一个人建置适合公司 130 人使用的系统。对于这个最终目标,他主动提供给公司的第一阶段目标是: 2 个月上线报价系统、2 年内完成所有系统。
据 Bill 所述,公司成立已经 30 年了,其中却有 20 几年都在查找一份适合内部流程的系统,但找了众多厂商 Demo ,就发现各家 ERP 完全无法符合公司的需求,就算要请厂商客制化开发,也很难找到有人愿意接下他们的案子。
举例来说,Bill 处理的第一个需求——将报价单从 Excel 转换成系统,就有让人伤脑筋的复杂规格说明。
在处理定价时,会先由总公司定期随着原物料的浮动调整各项制造项目的价格。调整完毕后,再将定价的 Excel 文件发给旗下的门市、再打印成打印件。
对于这种不同步的更新方式,Bill 提到曾经发生的实际情况:总公司更新定价之后,门市没有及时更新打印件,等到发现定价本缺了某些项目之后,才发现正在用的是好几个月前的版本。
而每个门市收到定价之后,会让设计师以人工比对的方式查询价格、输入数据,这也生成了“人工错误”的风险——只要时间一长、工作量一大,稍微闪神,就难免会发生错误的情形。
将报价系统搬到 Ragic 之后,得益于云数据库的特性,总公司只要在数据库更新定价,旗下所有门市都能在表单上“无缝接轨”,用新的定价制作报价单。这样一来,总公司就省去发送 Excel 定价本的步骤,更不用担心门市没有及时更新、用到旧定价的状况。
另一方面,透过链接与加载,设计师也不再需要手动输入价格。透过动态筛选来选择制造方式,让设计师省去翻找 500 多项的定价的时间,也不用再人工计算,直接由系统算出正确的单价。这样一来,大大减少设计师计算疏忽的可能性,也进一步提升专业性。
不过,这样的转换过程也不是一帆风顺的,对于设计师来说,要从相对自由、随时可以调整报价,方便给客户一些弹性的 Excel,转换到相对标准、SOP 化的“系统”,当然也会有一些意见、疑虑。
会不会不够自由、操作会不会很复杂……这些转换到系统时常见的疑虑,也不免俗地让 Bill 在建置系统的初期遇到一些阻碍。
实际上,因为 Ragic 并不是一个非常“硬性”的系统,要修改表单的设计十分容易,耗时也不用个几分钟,再加上 Bill 也考量到跟用户有所互动才能更快速创建一个值得信任、好用的系统。因此,他决定直接创建一个 LINE 群组,选择用更密集的步调,与用户一来一往交流意见。
为了促进使用率,首先应用他的专业制作了一系列图卡,说明 Ragic 的导入与基本操作,再将这些信息发到群组:
累积了一定的使用率,收到用户回馈之后,Bill 会根据这些意见调整表单的细部设置,并依据调整的内容,制作图卡、发布更新日志,来让同仁都能快速吸收信息。
举例来说,门市很常有“单价试算改数量”的需求:向客户提供不同数量的商品报价,让客户决定是否用更优惠的价格多做几件衣服。在过去,设计师可以直接拷贝 Excel 檔,直接更改里面的价格,但到了 Ragic,用户需要每一个数量都重新链接与加载,反而会觉得不顺手。
为了避免错误报价,Bill 最终加上了条件式格式与输入检查的设计,在编辑数据时如果发现错误的件数,就会以红底的方式警示需要修改,也要排调试误之后,系统才会许可保存。
这种实时、敏捷的系统开发,也曾经招致一些疑问:“没有 IT、软件开发会创一个群组的,都是每个月开一次会、提出需求然后一次改……”
然而,对于 Bill 与 Ragic 来说,这些所谓的“需求”其实都是短时间之内就可以改完的小问题。像是后续有设计师反应,希望系统能再提供一些弹性,例如:希望某个商品价格能有一些浮动的空间,Bill 就透过条件判断解锁单价字段,加上一个数值字段做加减,来让用户直接在最终金额做调整。
这些大量、却简单的繁琐细节不需要累积在一个月、一度的例会中慢慢解决,而是随时提出并马上修改设计,让系统与公司内部的用户能在短短两个月内步上正轨。直到现在,Bill 还是会时刻关注公司内部用户的回馈,针对需求实时调整适当的设计。
随着这样的策略,Bill 能感觉到公司内部对于 Ragic 的态度变得更积极:“只要可以满足用户的需求,同仁也可以越来越理解为什么需要做某些的限制与要求,也会更乐于主动提出系统的建议。”
看完 Bill 展示报价系统之后,我们很好奇的是:他并没有实际接触过各部门的工作,像是这种报价单,或是将在下一阶段上线的 CRM 的分配、样式,他是如何进行设计的呢?有问过相关部门的人员吗?
“其实一部分是照着公司既有的模式设计,先满足他们现有的需求,再去看其他现成的模板、系统有什么样的字段。”Bill 接着说:“可能问了相关同仁,他们也没办法直接讲出一个标准,因为过去并没有制定明确的 SOP。”
对于这种“大家心目中都没有什么最佳流程”的情况,Bill 的第一步往往都是先把公司目前设计好的 Excel 表、打印件单拿出来看,先把主要需求做好,后续再慢慢最优化。开始最优化时,独门秘诀就是上网恶补各种系统的视频、教学课程。“上 YouTube 看看不同产业跟需求的系统长得怎么样,大概会有什么样的功能。毕竟我也不是信息的人,没看过其他 ERP 或 CRM 长什么样子,也没有用过,但背后的逻辑都是一样的,就是表单、就是数据库,所以透过这种方式去了解。”
除了职涯历程之外,我们同样也非常好奇 Bill 成为 IT(信息技术人员)之后的一些个人经验与心得,因为我们通常也会把 IT 视为一种很会写程序、很高深莫测的职位、部门,但面对 Bill 这样“非典型”的 IT,我们也很好奇,突然跨入一个大家印象中需要一定门槛的领域,周遭的人们有没有感到惊喜或疑惑?
Bill 说,现在的职场上,大家其实不太在意你的“方法”,只要能够弄出一套系统,而且系统能够达成期望的效果跟目的,就不太会有人质疑你的能力,不会单独以“是否会写程序”这点来评断。
这段话不仅仅是 Bill 个人的经验,也与衣的艺术在查找系统时的经验相符:面对复杂的问题与需求,遍地找不到适合的系统商时,Bill 与他熟悉的 Ragic 确实就是一个适合的方法,只要能达成这个目的,Bill 当然也是一名合格的 IT。
看过 Bill 设计的报价系统,以及他描述公司同仁对 Ragic 的兴趣提升不少,我们也相信衣的艺术进一步转型、全面电子化的日子指日可待。
归类: 案例故事, Ragic 职涯故事