即刻App年轻人的同好社区
下载
我对【闪购便利店】这类挤压小微企业的需求感到反感，大企业利用供应链优化来进一步压榨小企业（夫妻店）的生存空间。这是把资金用在了刀把上，我感到很失望。因为这并不是大企业利用优势创造需求体验，甚至都不是一种资源整合，而是掠夺，掠夺小型个体户为数不多的生存空间。
1 00
在一家传统企业做了一年数据产品的感受：
业务的变化，变化的积累，人员的流动，组织架构的变动，权责的改变，人工的错误，以上各种因素交织在一起，都会让数据问题会错综复杂。
这种复杂性是天然的，是每个初期就未考虑【数字化】企业所必然面对的，一种较好的处理方式是通过数据问题反推业务流程和制度，【数据驱动】着企业发生变更。遗憾的是，大多数企业内部发起的变更，尤其是【自下而上】的变革往往不见成效。说白了，这是企业基因所决定的——当【数据驱动决策】的大锤没有击破传统业务的大门时，大家都会想当然认为这是没有必要且耗费巨大的投入。
常见的情况是，新人一看到这个样子数据信仰就崩塌了，能坚持下来的老人无一不是【知其不可而为之】，所以退而求其次，是选择维护现有的数据流通性。同样遗憾的是，这种维护不可持续，因为随着应用功能的迭代，过去以往的数据服务也会趋近于腐朽——原有的数据污染源不发生变化（这里我指的是制度层面，即数据准确性并且没有落实的人员管理上），数据服务腐朽的无非是早晚的事，维护只是一种【止痛药】。
不管任何时候，人，才是最主要的因素，而约束人的是制度，制度的建立又需要洞见，而这一点点洞见可能需要企业付出极大的代价才能被觉察。
业务的变化，变化的积累，人员的流动，组织架构的变动，权责的改变，人工的错误，以上各种因素交织在一起，都会让数据问题会错综复杂。
这种复杂性是天然的，是每个初期就未考虑【数字化】企业所必然面对的，一种较好的处理方式是通过数据问题反推业务流程和制度，【数据驱动】着企业发生变更。遗憾的是，大多数企业内部发起的变更，尤其是【自下而上】的变革往往不见成效。说白了，这是企业基因所决定的——当【数据驱动决策】的大锤没有击破传统业务的大门时，大家都会想当然认为这是没有必要且耗费巨大的投入。
常见的情况是，新人一看到这个样子数据信仰就崩塌了，能坚持下来的老人无一不是【知其不可而为之】，所以退而求其次，是选择维护现有的数据流通性。同样遗憾的是，这种维护不可持续，因为随着应用功能的迭代，过去以往的数据服务也会趋近于腐朽——原有的数据污染源不发生变化（这里我指的是制度层面，即数据准确性并且没有落实的人员管理上），数据服务腐朽的无非是早晚的事，维护只是一种【止痛药】。
不管任何时候，人，才是最主要的因素，而约束人的是制度，制度的建立又需要洞见，而这一点点洞见可能需要企业付出极大的代价才能被觉察。
2 00
时至年末，我的职业生涯又到了十字路口，最近的一年，我在一家房地产商业公司做数据中心服务，主要产出报表和可视化看板，我非常痛苦，什么痛苦呢？
数据的脏乱差，这点缺乏科技和数据思维的公司必不可少，可我似乎没有撬动原有制度齿轮的能力，上游在不断产出垃圾，最终数据报表和结果产出物成了背锅侠。
数据服务没有价值，几乎大部分报表都被用于考核，真正的分析，从数据中获取洞察的情况寥寥无几，取数、做报表、加指标、修正数据，每天如此循环往复，并且获得不了真正的认可——看不到价值。
数据的脏乱差，这点缺乏科技和数据思维的公司必不可少，可我似乎没有撬动原有制度齿轮的能力，上游在不断产出垃圾，最终数据报表和结果产出物成了背锅侠。
数据服务没有价值，几乎大部分报表都被用于考核，真正的分析，从数据中获取洞察的情况寥寥无几，取数、做报表、加指标、修正数据，每天如此循环往复，并且获得不了真正的认可——看不到价值。
1 00
作为数据人员，能做哪些事呢？
- 心态上调整：
业务的变化，变化的积累，人员的流动，组织架构的变动，权责的改变，人工的错误，以上各种因素交织在一起，都会让数据问题会错综复杂。
这种复杂性是天然的，是每个初期就未考虑【数字化】企业所必然面对的，一种较好的处理方式是通过数据问题反推业务流程和制度，【数据驱动】着企业发生变更。遗憾的是，大多数企业内部发起的变更，尤其是【自下而上】的变革往往不见成效。说白了，这是企业基因所决定的——当【数据驱动决策】的大锤没有击破传统业务的大门时，大家都会想当然这是没有必要且耗费巨大的投入。
常见的情况是，新人一看到这个样子数据信仰就崩塌了，但能坚持下来的无一不是【知其不可而为之】，所以退而求其次，是选择维护现有的数据流通性。同样遗憾的是，这种维护不可持续，随着功能的迭代，过去以往的数据服务也会趋近于腐朽，原有的数据污染源不发生变化（这里我指的是制度层面，即数据准确性并且没有落实的人员管理上），数据迟早会腐朽。
因为不管任何时候，人，才是最主要的因素，而约束人的是制度，制度的建立又需要洞见，而这一点点洞见可能需要企业付出极大的代价才能被觉察。
- 做事上调整：
华佗有两个哥哥，三人都是学医，但只有华佗的名气最大，因为他总是拯救病人于危难之中，于他而言：他两个哥哥的医术都在其上。 数据工作类似，对于过早的数据源干扰，其污染程度在一开始的业务流程和表单中是很难说有什么后果的（比如特批、数调以及人工干预的情况）
业务关注的是，我的流程什么时候能结束？我下一步需要做什么？我做多少时间这个事在系统上才算闭环？他们关注结果而非过程，因此对于过程中的录入质量全靠个人素质把控，除非流程到无法进行下去的地步，否则一切从简。那这些【质量低下】的录入会带来什么结果呢？业务上毫无疑问肯定是流程走完，已经入库的，而到了数据统计，这一切就变成了灾难，就比如一个地址字段，需要填写【金华市】，就有成千上百种写法： 浙江金华、金华、金华市、浙江省金华、金华 xx 街道...
后续统计需求一来，我需要查看在浙江省签约的项目，地址字段轰然崩溃。等到复查原因，才知道这一切都是上游字段的不把控，以至于统计才漏洞百出。但这一切是后验的，换句话说，不统计是完全不知道的，也无法在一开始就预料到这个情况，只能通过数据迭代、功能迭代来覆盖这一场景。此时，借助问题和报事的发生，数据影响业务应用的场景就变得自然而然，否则你去找人家，人家都不带理你的...
- 心态上调整：
业务的变化，变化的积累，人员的流动，组织架构的变动，权责的改变，人工的错误，以上各种因素交织在一起，都会让数据问题会错综复杂。
这种复杂性是天然的，是每个初期就未考虑【数字化】企业所必然面对的，一种较好的处理方式是通过数据问题反推业务流程和制度，【数据驱动】着企业发生变更。遗憾的是，大多数企业内部发起的变更，尤其是【自下而上】的变革往往不见成效。说白了，这是企业基因所决定的——当【数据驱动决策】的大锤没有击破传统业务的大门时，大家都会想当然这是没有必要且耗费巨大的投入。
常见的情况是，新人一看到这个样子数据信仰就崩塌了，但能坚持下来的无一不是【知其不可而为之】，所以退而求其次，是选择维护现有的数据流通性。同样遗憾的是，这种维护不可持续，随着功能的迭代，过去以往的数据服务也会趋近于腐朽，原有的数据污染源不发生变化（这里我指的是制度层面，即数据准确性并且没有落实的人员管理上），数据迟早会腐朽。
因为不管任何时候，人，才是最主要的因素，而约束人的是制度，制度的建立又需要洞见，而这一点点洞见可能需要企业付出极大的代价才能被觉察。
- 做事上调整：
华佗有两个哥哥，三人都是学医，但只有华佗的名气最大，因为他总是拯救病人于危难之中，于他而言：他两个哥哥的医术都在其上。 数据工作类似，对于过早的数据源干扰，其污染程度在一开始的业务流程和表单中是很难说有什么后果的（比如特批、数调以及人工干预的情况）
业务关注的是，我的流程什么时候能结束？我下一步需要做什么？我做多少时间这个事在系统上才算闭环？他们关注结果而非过程，因此对于过程中的录入质量全靠个人素质把控，除非流程到无法进行下去的地步，否则一切从简。那这些【质量低下】的录入会带来什么结果呢？业务上毫无疑问肯定是流程走完，已经入库的，而到了数据统计，这一切就变成了灾难，就比如一个地址字段，需要填写【金华市】，就有成千上百种写法： 浙江金华、金华、金华市、浙江省金华、金华 xx 街道...
后续统计需求一来，我需要查看在浙江省签约的项目，地址字段轰然崩溃。等到复查原因，才知道这一切都是上游字段的不把控，以至于统计才漏洞百出。但这一切是后验的，换句话说，不统计是完全不知道的，也无法在一开始就预料到这个情况，只能通过数据迭代、功能迭代来覆盖这一场景。此时，借助问题和报事的发生，数据影响业务应用的场景就变得自然而然，否则你去找人家，人家都不带理你的...
1 01
当我们在说“MySQL 库”的时候，我们在说什么？
实际上，我们通常认知里的 MySQL、Orcale、PostgreSQL、Doris 几乎都是数据库管理系统（DBMS）。真实使用过程中就会发现：DMBS 是需要安装在某个服务器上，服务器配置了主机名和端口连接。在你成功连接数据库管理系统后，如果配置的数据库账号有权限，还可以自行创建新的自定义数据库。 这个操作权限说明，以上各个我们所所知的“叫法”其实都是指向数据库管理系统。如果你需要访问真正存数据的地方，还是要明确到带有自定义名称的库。
不过还有一种情况，可能会遇到“mysql 库”这样的叫法，但这个库其实是数据库管理系统内置的、与自身 DBMS 同名的数据库。并且通常为了避免干扰和遇到未知的错误，业务开发也尽可能不会使用内置的数据库，最好的做法就是单独创建一个新的数据库来存储特定应用的数据。
实际上，我们通常认知里的 MySQL、Orcale、PostgreSQL、Doris 几乎都是数据库管理系统（DBMS）。真实使用过程中就会发现：DMBS 是需要安装在某个服务器上，服务器配置了主机名和端口连接。在你成功连接数据库管理系统后，如果配置的数据库账号有权限，还可以自行创建新的自定义数据库。 这个操作权限说明，以上各个我们所所知的“叫法”其实都是指向数据库管理系统。如果你需要访问真正存数据的地方，还是要明确到带有自定义名称的库。
不过还有一种情况，可能会遇到“mysql 库”这样的叫法，但这个库其实是数据库管理系统内置的、与自身 DBMS 同名的数据库。并且通常为了避免干扰和遇到未知的错误，业务开发也尽可能不会使用内置的数据库，最好的做法就是单独创建一个新的数据库来存储特定应用的数据。
0 00
