在之前讲过，缦图用盖雅是为了解放门店算薪的人力。
当时人力总监考察了市面的系统后，发现只有盖雅能够支持我们的复杂逻辑，咱受对方蛊惑，听信了对方是考勤业界的王。
盖雅工场需要咱将员工与部门数据同步给他们，这看起来并不是啥麻烦事，我原本是这样以为的。
开幕雷击，可能还是我见的世面少了，系统对接使用文件传递，需要以 csv 文件方式将员工的增量数据放进他们的服务器。
通过询问后知道，他们每次对接都是这样，都是进行定制开发（表头不一致），没有统一的处理方案。
这样就导致我们的进度是完全依赖于对方的，就算我们是甲方，也没有说能百分百控制住关键时间点。咱们的业务分与对方沟通了数次之后，终于确定好了各字段内容的格式。
业务方偶尔反映数据有问题，这时没有一个判断依据，因为对方每次处理完文件后都会删除掉，我们的文件也在容器里。更窒息的是对方没有错误提示，要登录服务器才知道同步因为报错卡住了！就很好奇这样的方式之前没人吐槽过吗。并且他们的逻辑是一个文件里遇到一行错误，剩下的就不执行了，而且之后的新文件也不执行了
对方也是急需吃下我们这个大单，再经过很多次的反馈后，对面逐渐重视，由领导来牵头解决了对接中的一些情况。经过我们持续优化后，终于保证了整个业务高可用。
上线后，由于之前员工都习惯了钉钉打卡，改用盖雅的 H5 后不熟悉，并且 UI 简直是十几年前的画风。我方提出了几点来兼容使用习惯，例如增加查看打卡记录的入口、自动打卡、修改 UI 等，又需要对方进行排期与估价。一点小修改开出了 18w 的报价，所以我们决定自己出 UI，让他们直接替换掉。
“业界领先”的系统连很多基础功能都没有
经过几个月的折腾才完成了整个计划的前奏，关键的目标是用对方提供的考勤数据来计算薪资，所以咱还得接着开发。
果不其然，整个数据又是放在他们服务器，让我们去取。但是直到上线，对方都没有保证每个月什么时间点能生成好数据。
现在回头看看最初的目标，由于对方生成的文件数据并不准确，还是没有解决算薪的问题，需要花整个部门（三支柱的SSC）的几天通宵去验证对方数据准确性。
