2019年终总结

工作

2019

我目前能负责的主要工作集中在Sailing框架和ERP6.0, 19年初制定的总体目标如下:

• 不断打磨Sailing, 提高开发效率;
• ERP6.0实现出口, 进口, 内贸业务覆盖;
• 完成若干ERP6.0项目, 实现收款300万;
• 扩大ERP6.0的开发和实施队伍;

2019年第一季度, 东方一期第三批用户上线, 这也是东方14家子公司中最难的一批用户, 有不少个性化需求. 于此同时, 中大项目正式开始现场实施工作, 开发组(忠斌, 我, 黄谦, 何思义, 吴兴强, 陈春雨)的主要精力都集中在项目上, 其中忠斌和陈春雨项目还两边跑, 但即便如此, 我们还是尽量保持何思义和吴兴强的主要精力放在框架改进和产品研发上, 这么做当然主要是为了保证框架和产品能不断小步推进, 但除此之外, 项目上不断提出的新需求也需要框架的持续跟进调整来保驾护航, 这一点还在第四季度得到了反证.

第二季度项目压力稍小, 我们的主要精力集中在ERP产品开发上, 因为中间插入了兰生和其他项目占用了部分精力, 产品开发进度稍有延迟, 7月底完成了出口, 进口, 内贸业务的覆盖;

第三季度东方二期开工. 我们内部评估应该有余力继续推进ERP6.0的场景覆盖, 于是开始基于Sailing框架的财务系统的预研和正式开发工作. 到9月中下旬完成了凭证制作和智能核算框架, 部分完成了整个账务系统的设置功能.

第四季度, 东方二期进入关键阶段, 另外又签订了两个新ERP6.0项目, 此外, 兰生, 机电, 汇鸿, 土蓄等项目也吃紧, 需要ERP组的支持, 我们内部评估后决定全力支持项目, 暂停了所有产品和框架的开发工作.

综上所述, 19年完成的工作如下:

• Sailing框架持续改进;
• ERP6.0完成了出口, 进口, 内贸业务场景覆盖;
• ERP6.0启动了财务系统的开发工作;
• 截至目前, 东方项目还遗留财务接口未完成(机电项目很紧张, 内部讨论决定弃东方保机电);
• 协大项目已上线, 但财务的细节部分还在持续调整;
• 若远项目已上线, 估计年后并行2个月可以验收.

回顾年初的规划, 19年的这个结果, 有达到甚至超过预期之处, 也有不尽如人意的之处, 还有些方面完全没有成效. 以下详述:

• sailing
  Sailing框架经过了2年多的开发, 个人认为已经在项目中实证了其所具有的能力. 举两个例子说明. 一个是宁波若远对比宁波贝发, 前者的业务模式虽然比后者简单, 但管理细致程度有过之无不及, 公司经营活动的IT覆盖率更是我所知道最全的, 项目组评估下来, 总体项目难度接近贝发二期. 这个项目其实是从PB组转过来了, 从这点也可以看出项目难度几何. 但整个项目从调研到上线只用了3个月, 合计10个人月(含业务/财务系统开发, 调研, 实施), 这个数字还是在其他项目频繁插入的第四季度. 而(印象中, 没有具体系统数据支撑)贝发二期持续了近半年(相比一期已经进步不少), 长期参与的成员3-5人, 高峰期8人在现场. 两相比较差距十分明显. 如果说这个差距是由于项目组成员的经验引起的, 那么中山丝绸和浙江东方这两个对开发组来说背靠背的项目可以说明一定的问题. 就开发规模而言两者相差不大, 细致程度中山更胜一筹. 和中山项目16年11人大团队集中开发近半年, 现场实施阶段还是磕磕碰碰相比, 东方可以用轻松来形容.
  除此之外, Sailing还支撑了兰生预警系统, OA系统, SSO系统(仅管理端), 大屏系统(仅后台服务).

• ERP6.0产品覆盖
  19年基本实现了预期目标, 实现了出口, 进口, 内贸业务的覆盖, 其中出口模块已经有不少实际项目案例, 包括: 浙江东方(服装), 中大技术(医疗设备, 服装), 协大(服装), 若远(灯具); 进口模块中大技术项目有包含, 但使用力度忽略不计; 内贸模块没有实际案例.
  但产品覆盖是一回事, 产品深入又是另一回事. 对于目前我司的状况, 产品覆盖可以通过集中开发实现, 甚至其中的某些市场亮点也可以通过集中开发来实现, 但产品功能的专业性, 细节的打磨等必须有来自实际项目的需求, 否则很难深入.
  此外, 目前总体感觉财务系统瓶颈很严重, 主要体现在人力资源捉襟见肘, 希望能通过新财务系统的实施, 使现有的业务开发人员都具备基本的财务开发技能.

• 收款
  直接收款项目

  项目	收款(万元)	说明
  东方	54.1	一期尾款+二期第1笔
  中大	0.0
  协大	45	第1,2,3笔
  若远	19.5	第1,2笔. 第3笔1月10日已付未计入
  上海电气	8	维护
  领尚	1.65	维护
  合计	128.25

  显然没完成. 我认为原因有二:

  1. 签单都达不到, 收款更无从谈起; 签单达不到的原因可以归结到产品功能覆盖不完全, 但下半年的新单是否是功能覆盖完全的直接结果? 总之, 这是个先有鸡先有蛋的问题, 还是需要产品和市场(不是销售)团队通力合作才行;
  2. 即便签单的前提满足, 收款也未必, 因为以产品组的现有资源, 如果完成了收款任务, 那么产品和框架的推进基本上是天方夜谭, 甚至可能影响对其他项目的支持工作. 我认为对产品组设置收款任务是对权责清晰化工作的一种破坏, 第三部分的项目和产品分离问题上稍微讨论下.

• 培养队伍
  这是19年最失败的一件事. 这件事又分两块, 两块都很失败.
  一块是现有成员的转移. 原计划今年全顺通团队应该有相当部分的可以参与ERP6.0的开发和实施工作, 但有由于各种原因, 仅在第四季度迫不得已的情况下, 才有园园参与了协大项目, 豪哥参与了若远项目. 还算可喜的是, 园园和豪哥基本可以认为已经入门了. 其他人没有参与进来的客观原因是兰生项目的严重拖延和过度资源占用, 但个人认为还需要深入分析. 此外, 需要进一步了解现有全顺同开发人员是否有意愿参与新ERP6.0的项目实施工作, 有反馈说不少小伙伴表示无意工作于此类私有开发平台上的, 原因是不符合个人职业规划, 但没有求证. 无论有无此情况, 都应该调整并统一开发平台的宣传基调, 尽量打消这类思想, 不能听之任之, 更不能鼓吹.
  另一块是新人的招聘. 这一块我和林爷以及行政部的协调上可能有点问题, 若干次出现在招聘与否的问题上的沟通失误. 此外, 我早期的招聘目标是寻找可以参与到产品核心开发组的成员, 后期的意图其实已经调整成了可以参与新ERP项目实施的成员, 但对于招聘要求是否太严格这点需要检讨.

2020

以下对2020的展望均为基于现状, 对于是否能突破现状的一些想法, 放在第三部分.

• 继续推进Sailing框架持续更新
  我认为Sailing框架的升级应该作为一项长期任务来对待, 在Sailing的整个生命周期内, 应该持续更新以适应新需求, 持续重构以应对下一次变化. 这虽然是所有事项中最没有直接经济价值的一个, 但却是所有事项中性价比最高的一个, 19年的案例已经说明了这点. 我们的中期目标是达到甚至超越PB的开发效率. 这是有可能的, 其依据是PB平台需要适配的场景比我们多得多, Sailing平台仅需要考虑适配类似供应链系统这类单据驱动的应用, 场景复杂性低.
  另一方面, Sailing还需要尽快走上版本化发布更新的导入, 这样做的好处在目前支持项目不太多的情况下不明显, 但大量项目上线后, 目前的更新发布节奏会引起项目上版本控制的混乱.
• 在上半年培养起一支能实际实施ERP6.0项目的队伍
  按照目前和往年的情况, 2020年下半年, ERP6.0的项目量将超过现有人员能承受的极限, 也就说就算产品组完全不搞产品专搞项目, 也搞不过来了. 因此必须要在上半年就做好准备了. 希望能建立2个项目开发组(每组1项目经理+1项目开发).
  要做到这点, 还是需要两方面着手. 首先是内部人员的转换, 这个的前提是需要加强产品组和项目组之间的协调(目前协调很少, 产品组是特种部队式的作战).
  此外是外部招聘, 建议全年招聘.
• ERP6.0产品提高覆盖, 增加深度
  目前明显缺的部分有库存管理和财务系统. 库存系统需要覆盖实物库存的管理, 支持多仓库; 财务子系统需要覆盖现有财务系统的所有功能.
  需要深化的内容就更多了, 比如, 目前以建立了任务驱动的机制, 但场景还不够丰富, 需要在这个骨架的基础上有血有肉; 目前的系统主要功能是支持业务的事务过程和沉淀数据, 对数据的利用还很少, 需要通过几个场景来支持新ERP6.0能帮助提高企业主的洞察能力的口号(比如未来预计现金流). 还有很多, 开发组有份TODOLIST, 择一二实现.
• ERP6.0的项目能实现400万收款?
• 建立ERP6.0的项目实施体系. 这个话题很大, 2019本来想搞的, 但第四季度项目压力实在太大, 没有精力整.

其他想法

这一块很杂, 都是些平时支离破碎的想法, 正好趁这个机会整理下, 纸上谈谈兵.

收入

要么创造溢价, 要么向规模要效益.

• 营收多元化
  看到孙总总结里签单额断崖式下降的说法后, 其实很感概, 因为这件事并不是无法预见的"黑天鹅", 而是未发生而注定会发生的"灰犀牛".
  首先, 国内对国际贸易的开放程度总体显然是越来越高的, 这一方面降低了国际贸易门槛, 有利于总量做大, 但另一方面也使得"国际贸易行业"越来越不能称其为"行业", 而以国际贸易行业专家自居的我们, 这无疑是一头慢慢向我们撞来的灰犀牛, 近几年的国际贸易形式仅仅是让这头犀牛跑的更快了一点. 而外部环境对一个企业个体造成的影响的非线性化, 已经在上一次互联网浪潮中一次又一次的证明了.
  其次, 这几年我们似乎更加倾向于所谓的"大客户", 大客户确实能树立市场口碑, 能创造销售业绩, 但与此同时, 大客户也需要更大的资源投入, 以及承担更大的资金流风险. 假设做项目存在固有的10%的项目失败风险, 一个100万的项目和10个10万的项目虽然预提项目风险金是一样的, 但100万的项目一旦发生问题, 将大大超过预提金额, 直接影响现金流, 10个10万的项目却没这个问题. 对这个100万的项目来说, 失败是个"黑天鹅", 而对做一个100万的项目还是10个10万的项目这个抉择来说, 这就是个"灰犀牛".
  我在这里并不是说不要做大项目, 而是希望能对小项目路线做适当的探索; 不是说不要做外贸行业, 而是希望如果有机会, 能在其他行业做适当的探索. 利润的过于多元化不见得是好事, 但目前过于单一总是有问题的.
• 概念包装, 产品升级
  如果我们的客户群定位为高端大客户, 那么目前的产品客单价(不是人天单价, 人天体现的其实不是产品的价值)相比同行(用友金蝶南北)是低的, 低的原因是产品严重缺乏包装. 同样的功能, 引入一套理论, 换一种组织方式, 也许就能提升一个档次, 但目前我们不具备这个能力. 我们的顾问团队大拿们(当然也包括我)急需将自己倒空, 重新学习充电.
• 产品线配合
  我们做过不少东西, 但这些产品之间的配合不足, 没有1+1>2. 我认为主要原因是各产品线各自负责, 公司层面缺乏一套协调机制. 我们这样规模的公司, 其实完全不必分多个产品开发组, 统一管理协调是最好了.
• 新产品商业模式上的探讨
  现在新的产品在实际项目商务操作上遇到不少困惑, 比如我们如何介绍我们的Sailing框架, 这个框架最大的优势是压缩成本, 其实是和客户无关的, 我们是否需要对Sailing做更加低调的处理. 另外, 有些对技术比较感冒的IT负责人会对这块感兴趣, 这时候又该怎么办.
  再比如, 全顺云目前的收费方案是否合理. 拿最近的客人慈溪若远来说, 他们去年3000万美金的量, 最近有成交记录的100家左右的工厂, 每个工厂查询8个项目, 合计2.1元, 预计每季度查询一次, 检查TOP 10%的工厂, 一年营收84元; 如果遇到大方的客户, 改成每个月查询一次, 每次查全部的工厂, 一年营收2520元. 全顺云运营费用一年按5万算, 那么盈亏平衡点就是50000/2.1=23810次, 也就是需要6亿美金大方的客人或者179亿美金小气的客人, 我不知道数据获取渠道的动态成本是多少, 所以没考虑这块. 因为这部分数据对自营客户的用途远大于对代理客户的用途, 有实际需求的往往是自营客户, 而我们要在自营客户中做到这个数字, 目前是很难, 况且还有对收费之后服务质量的担忧. 全顺云的另一大作用是云端数据沉淀, 这个是我们不能放弃. 既然数据服务直接变现很难, 而服务本身又必须保留, 那么我们为什么不考虑这部分费用隐性包含到项目维护款中, 然后以一定量(基本足够客人日常使用)免费的方式提供这项服务呢? 这么做可以规避不少项目风险, 商务上也容易处理.

成本

全顺虽然十多年了, 但规模上还是个小公司, 一切要从简.

• 统一技术栈
  从全顺成立那一天起, 我们就一直承受着技术平台分裂导致的额外无形成本. 最早是PB和.NET, 后来是.NET和java. Sailing框架选型的时候, 我放弃自己.NET的专长而选择java也是基于统一技术栈的考虑. 但令人遗憾的是, 后端是统一了, 但前端却又分裂了. 在Sailing框架的前端已经成熟的前提下, 大屏产品线选择了另一套前端框架, 实在令人费解. 技术选择有个人喜好成分, 这无可厚非, 但切忌个人喜好占上风.
• 要建立产品预算机制
  近几年我们新开了不少产品线, 最大的自然是ERP6.0, 另外还有不少探索性质的, 比如全顺云, 大屏等. 但所有这些都缺乏相对透明的产品规划形成办法, 全凭产品负责人的设想.
  我认同一款产品只能有一个主设计师, 因为我认为一款产品的设计, 不能等同于一个工业品生产过程, 而更应该类比成一件艺术品的创作过程. 很难想象在梵高星空的映照下, 莫奈的湖泊波光粼粼, 其中还游着一条八大山人的鱼...
  但一款产品的设计毕竟不是一个人能完成的, 需要占用公司资源, 公司有必要监控研发方向和进度. 协调这两者的最佳实践不是绩效考核, 而是预算, 预算能在不直接干预研发过程的情况下, 对其进行把控.
  预算算什么有多种定义, 预算的形成也有不少办法, 我觉得最适合现阶段我们公司现状的预算定义是人力资源+部分费用, 因为研发工作是由门槛的, 其实不太可能过程中动态变化, 而现阶段能参与研发的人其实也就那么几个, 那么就没必要将人力资源再折算成费用了. 而最适合目前的我们的办法是, 公司确保参与项目的资源, 各研发组提交目标和需要匹配的资源, 最后双方协商确定. 因为产品开发的几乎所有工作都在现在的研发部, 而无论是ERP组还是参与全顺云和大屏等产品的小伙伴, 都是又红又专的, 标准预算形成方法中那些为建立互信而设的反复确认步骤可以省去.
• 产品和项目分离
  由预算制其实可以推导出产品和项目分离的结论, 换句话说, 产品项目不分和预算制是冲突的. 举个例子, 年初建立了一个项目预算案, 投入开发组甲, 最后甲因为参与了项目A而没有完成产品开发, 决算的时候, 这个预算案还成不成立. 假如甲为了完成产品开发而延误了项目交期, 项目上又该如何考核. 一般来说, 项目上的都是急事, 产品上的都是重要的事, 这两者产生冲突的时候, 重要的事必定让位于急事, 从而在整体上造成损失.
  这个问题一旦和绩效考核挂钩后将更加复杂, 无论哪种情况都会造成产品和项目的负和博弈以及甲的价值观分裂.
  19年第四季度的情况其实就是上例真实的写照, 原本的开发计划因为项目压力而被迫取消, 新人因为项目压力而无法加入, 短期推动的项目, 长期来看打乱了整个产品部署节奏. 被项目挤占的框架待开发部分, 一个月后影响到了项目.

利润

利益, 目标, 行动一致

• 产品和项目分离
  如果产品和项目团队实现了分离, 那么绩效产生办法的分离是自然而然的事情.
• 产品采用okr, 考核主观为主, 不关联绩效
  产品团队如何做绩效考核, 这个问题我想了N年, 百思不得其解, 早些年也实践了不少办法, 有些沿用至今(全顺通团队), 有些放弃了. 现在看来这些办法或多或少要么成本偏高, 要么隔靴搔痒. 我也向周围的朋友, 同行请教过, 其中不乏比较成功的企业, 也莫衷一是, 但总体的思路都是以主观考核为主.
  这两年我也想通了或者释然了, 绩效考核是把双刃剑, 同样的方法, 在不同规模, 不同模式, 不同组成的公司会有不同甚至相反的效果; 另一方面, 因为绩效考核要求量化, 而这需要KPI指标遵循SMART原则, 而产品团队的工作很大一部分是无法量化的, 或者在最终可量化之前, 需要经历很长的一个不可量化的阶段, 这个尴尬也导致了google, 微软, facebook等公司放弃绩效考核(因为这些公司的主要成员全都是产品团队, 很少是项目型的), 转而使用OKR+主观考核的办法.
• 项目考核在各阶段一致
  项目团队天然的项目属性为采用绩效考核作为激励手段提供了条件. 个人为人目前的考核办法没有什么大问题, 但有可以改进之处. 一个是销售团队和项目团队其实目标是天然一致的, 仅仅是分工不同, 那么有没有可能将两者的考核也打通, 计算基数一致, 都用销售毛利, 节点一致, 都采用收款阶段分段. 毕竟利益一致了, 目标就一致, 目标一致了, 行动就一致. 不知道这样是不是能解决现在销售和项目团队时不时的冲突.
  另一个是说了好多年的打破大锅饭. 这个问题其实比看起来的更复杂. 据我了解到的情况, 开发部的项目经理们并不满意现有的考核模式, 越优秀的项目经理越不满. 但是, PB组能实行完全阿米巴式考核的前提是, 每个人或者每个固定团队都能独立作战. 而开发部目前的情况是没有足够的个人或者固定小团队可以独立的做项目. 这就造成项目经理们即便不满, 也没有办法, 因为他们不得不借助开发团队的力量, 也就不得不和项目经理分享开发团队, 这种全面的共享(PB也有共享, 但是是偶然的, 可以case by case解决的)导致了项目经理之间的绩效的平均化, 这个是优秀项目经理不满的来源. 而普通项目经理的不满来自于项目经理和开发组成员之间的纵向比较, 我们的项目经理很多有技术背景, 本身也是开发人员, 年终绩效揭榜, 当他们认为开发组成员或者开发组和项目经理之间存在错配的时候, 这种不满就产生了.
  很大程度上, 这些不满是无法避免的, 但细粒度的阿米巴可以使情绪局限在组内, 完全到个人的阿米巴则回避了这个问题. 所以我觉得问题的关键不是如何考核到人, 而是首先要不要保留共享开发团队的机制; 如果不要, 如何提高独立作战能力. 前一个问题是需要抉择的, 后者又是个先有鸡还是先有蛋的问题.