Hey，大家好！
欢迎来到互道信息的“元宇宙世界”！这里是元宇宙第七期专栏。
我们打造了一家虚拟零售公司，在一群志同道合伙伴们的努力下，公司规模不断扩大，业务类型持续增加，并吸引了众多优秀人士的加入。他们充满朝气且各有特点，他们的故事普通而有趣……
Ada最近有点慌，一波未平一波又起。
事情是这样的：Ada发现了东区店长能看到南区店长那边的数据，也就是说，只要是店长，不论哪个区，大伙儿的数据权限是一样的。这意味着数据一旦泄露将给品牌带来巨大的损失以及飞单等各种潜在的风险。
心有余悸的她赶紧跑过来告诉Frank……
Ada：Frank，我有点慌。
Frank：又咋了。
Ada：我在巡店的时候，发现东区店长能看到南区店长那边的数据，也就是说，只要是店长，不论哪个区，大伙儿的数据权限是一样的。
这就非常危险了，千防万防，家贼难防！再安全的数据管理，都难防“有心人”的第三只眼。可能会导致飞单等各种隐患。
可是按理来说不应该呀，为什么会发生这样的事啊？
Frank：
ok，我懂你的意思了，之前我们的数据权限管理还是比较粗放的。
不过前几天互道的CTO正好来和我聊了这个事儿，我也学习了一下。企业完全可以在传统的用户、角色、权限、资源之外，结合ToB的业务场景，特定引入“组织架构”、“岗位”和“规则”。
简单来说，“大店长”是一个角色，但是”东区大店长“和”南区大店长“是两个不同的岗位，访问权限按照岗位来设置的话，东区大店长就只能看到东区的数据，南区大店长只能看到南区的数据，这样就做了多维度的数据隔离，保证了数据的安全。
Ada：
哇大佬就是大佬，一下子解决掉了我的恐慌，让我茅塞顿开，是一个不错的创新之举了！！
Frank：
目前市面上大部分产品设计都只能涉及到店长的角色，还没办法分区域。而互道和我说那些是真正站在ToB运营的角度把颗粒度打得更细。他们在最开始设计技术架构的时候，就想到了需要根据业务特性把“job”这个数据对象考虑进去。
这就好比，公司建10层的大厦和100层的大厦，最开始如何把地基打好是完全不一样的。
基于互道技术的可扩展性，我后台配置并升级，你明天让店长们把软件更新一下，这个难题就解决了！
Ada：
太棒了！
可以说是非常有前瞻性了。
Frank：
数据权限是数据驱动的安全带。我也是和供应商一起学习成长，从踩过的坑中总结出来了一系列的经验。技术构架设计要在夯实企业技术底座的同时，又能很好的匹配业务的需求。
保障数据安全一定是最基本的标准需求，在此基础上，企业才能拥有更多的主动性，能动性。
Ada：
说到我心坎了，数据权限拿捏住了！
相信我们在接下来的门店数字化进程中能够更加如鱼得水~