在数字化时代，物联网和低代码技术正逐渐改变着我们的工作和生活方式。本文将深入探讨数智化物联网平台的发展，特别是低代码理念在物联网领域的应用和物模型的演化。
近期学习低代码产品的设计理念，在不同平台上看到了很多观点，有的人认为低代码技术是福音，特别是国内外IT大厂的官方说法，总体对其保持乐观态度。也有很多人抛出了低代码简直就是“毒瘤”的观点。
在学习过程中，尤其是了解新事物的过程中，我们始终都应该带着批判性的思维去看待各种观点，与直接认同某个看起来正确的观点相比，深入了解发言人的立场、了解他为什么抱有这种观点，才是更高层次的学习方式。
低代码所处的位置比较尴尬，很多人认为其恰恰处于一个半吊子的位置。尤其是从大多数程序员的视角来看，低代码这个东西的定位非常鸡肋。
首先，对于非技术人员，比如产品、运营、销售甚至是甲方客户来说，低代码的操控并不算便捷，上手是有一定难度的，并且还需要系统的学习，才能初步掌握其使用方法。
而对于开发者来说，低代码的自由程度和灵活性跟真正的代码肯定无法比拟，一些用户的灵活需求，如果要是一开始设计的低代码系统能配置还好，如果不能配置，最终还是得在底层进行修改，而且修改起来肯定比直接按需开发的系统费劲的多。
这个东西就像混动汽车一样充满争议，混动汽车的动力系统介于油车和电车之间。认为它好的人，认为它平时既能烧电省钱，万一充不上电还可以加油续航，不用担心趴窝，满眼都是它的优点。看不起混动汽车的人，认为它烧起油来比油车费油的多，动力又不太足，总之满是槽点。
其实，无论是用来举例的混动汽车也好，还是低代码这个工具也好，处在中间位置的这类工具，必然是优劣兼具，甚至还将某些优势和劣势进行了放大。关键还是要明确使用场景和使用者，之后恰当地使用该工具，从而扬长避短。
讲到这里，我们需要明确低代码这一工具，真正的使用者应该是谁。笔者认为，应该是数字化转型技术厂商的“产品运营”或“售后/售前技术支持”。总而言之，应该交给乙方的非技术人员使用。这些专门人员在经过合理的上岗培训后，也会熟练使用低代码工具。
与此相匹配的工作流程是：产品研发者在大量项目中不断积累经验，开发出不同场景下对应的低代码产品，之后由乙方非技术人员操刀，通过与客户进行持续沟通，使用低代码工具为同场景下不同的客户配置并交付符合其使用习惯的最终平台，并在实际使用过程中发现问题，提出需求，为研发团队迭代优化低代码产品提供依据。
（图片来源：点维数智PM原创）
任何一家提供数字化转型服务的技术厂商都会告诉你，不同行业、甚至同一个行业的不同公司，数字化产品的设计都是千差万别的。然而等他们以各种方式拿下项目后，研发人员一定都会想着在做系统时，能不能照搬和复用之前做过的系统，实在不济，参考着改一下也行。
数字化转型产品，到底是走向标准化还是定制化，其实是一个难以抉择的问题。对于数字化转型解决方案提供商来说，走标准化路线意味着可以大量、快速地复制并推广其产品，从而极大减少边际成本，实现持续盈利，也可以薄利多销，让数字化转型技术普惠更多受众。
另一方面，基于用户使用体验来说，客户也期望看到数字化转型服务商深入其一线调研，并对其实际出现的问题进行深刻的理解，并最终交付与其业务流程高度匹配的产品。客户的想法也很简单：“既然我给你钱了，那你的眼里只能有我，不要拿给别人做的东西复制过来糊弄我。”
而笔者个人的看法是，数字化产品也趋向于走入标准和定制的中间态模式。当然，这种和稀泥的结论，也意味着产品设计者需要结合具体情况，审时度势，能力要求和主动程度都需要进行大幅度的提升。
在浏览过大量的项目案例后，笔者发现，在很多产品场景中，使用低代码可以很好地解决系统在标准化和定制化之间的平衡问题。
流程引擎其实就是一个非常好的例子。目前很多低代码或零代码产品，都习惯性地往OA工具上发展，这就是因为低代码高度灵活性和可配置性的特点，实实在在解决了企业审批系统的痛点。
比如说，一个大型制造业企业中，不同事业部、不同部门和不同产线上，审批流程花样百出。还有的需要加很多规则在里边，例如“资金超过200需要领导审批，低于200自动通过”。再加上频繁的人事调动，也意味着审批环节上的每个人都需要及时更新。
假如所有的流程都是研发同事们直接开发出来的，那对于这种变动非常频繁，规则复杂且繁杂的应用场景，几乎每天都需要不断迭代，耗费大量开发精力。
所以，如果OA系统灵活可配置，在日常运营过程中，即使流程千变万化，也只需要安排一些普通员工随时配置即可。现在的OA工具，低代码基本已经占据主导，但在其他领域，笔者认为，这种产品理念贯彻地还不够深入。
（图片来源：点维数智PM原创）
接下来，笔者将通过自己设计的产品案例，来进行低代码这一产品理念在产品设计中应用的复盘。在实际项目中，笔者对这两个产品进行了大胆创新，虽然还有很多地方需要完善，但这两个案例，在低代码解决数字化项目中标准与定制之间矛盾的问题上，已初具雏形。
楼宇自控系统一般会在智慧楼宇项目中体现。我们平日所见的高楼大厦，内部都安装着复杂的电气设备，来保障楼宇内环境的舒适。其中包括调节温度的空调系统、保持室内环境清新的送排风系统、以及常见的给排水系统、变配电系统、照明系统等。
楼宇内各种系统的详细工作原理，日后再与大家做详细讨论。在数字化项目中，针对楼宇自控系统，我们一般需要做如下功能：
笔者在设备台账管理、数据监控和下发控制命令层面，引入了低代码的设计理念，设计了一套自由，可配置化程度比较高的通用型产品。
首先，要想实现楼宇自控的基础功能，大体需要规划两个模块，一个是软件平台，另一个是协议解析模块。
先说协议解析模块，如果我们遇到比较好的硬件商家，从系统平台上直接提供API接口，那开发就可以直接写代码对接了，省时省力。如果硬件商家提供的是遵循某个协议的数据传输服务，那我们就需要解析协议，并封装成标准接口或消息推送，常见的物联网传输协议包括obix、modbus等。
总之，提供给软件平台的，必然是已经封装好的标准化接口，按照以往的开发方式，我们都会先按照客户需求，开发好对应的界面，之后由开发同事进行接口对接，提取数据进行分析，并做一些按钮，下发控制指令。
这样做的劣势是，系统的定制化属性太强，特别还是智慧楼宇这种，不同客户差异性比较大的项目，几乎每换一个客户，都要重新开发一次。而且还需要拿到所有电气及弱电系统的点位、设计图之后，才能进行分析、开发，不仅开发量大，工期也难以保障。
所以，为了使系统更为灵活，笔者从数据角度出发，对点位数据进行分类整理，设计了一套智慧楼宇低代码产品。产品部署完成后，可以由非技术人员进行配置，在拿到设备点表以及接口列表后，可以快速配置并上线。
（图片来源：点维数智PM原创）
对智慧楼宇场景下的数据来说，如果按照数据类型来划分，总共也就数字类型和模拟类型两种。工科的同学可能清楚，数字类型无非就是0或1，例如设备的开和关，设备的在线/离线，就可以用0和1来代替。模拟类型则代表连续值，例如温度值、湿度值等连续且可以在一定范围内任意取值的数据指标。当然，在实际场景中，受制于设备采集精度，也只能取离散值。
如果按照功能类型来划分，所有的数据分为两种，采集数据和控制数据。例如某些接口中的数据，我们需要调用接口将其采集上来，而某些接口中的字段，我们可以通过调用进而控制其开关或进行温度、湿度等数值的设定。
基于此，我们可以开始设计智慧楼宇低代码管理系统的雏形。首先，在主页面设置一个列表，列表横向分为三个区，一是设备信息区，用来导入设备台账；二是数据采集区，用来读取各个点位所检测的数据；三是控制指令区，用来手动发送控制指令。
在设备信息区，我们可以添加一个导入功能，将设备台账中的设备导入进去，并且获取其设备ID。这样就可以明确，每一行数据在调接口时，采集的是哪个设备的信息。当然，在设备信息区，我们也可以随设备台账加入其他设备属性，例如设备名称、设备位置、设备自定义编码等。
在数据采集区，我们可以逐个为指定设备添加一个个需要采集上来的字段，在配置每一个字段时，我们需要配置以下几点信息：
控制指令区与数据采集区的道理基本相同，我们在控制指令区配置控制字段时，每个字段都需要配置字段名称、字段类型、接口地址和对应字段这几项，不同的是，数据采集区录入的对应字段要从接口的输出值中找，而控制指令区录入的对应字段要从接口的输入值中找。
（图片来源：点维数智PM原创）
以上章节都是在没有相关理论知识储备的情况下，作为一个新入门的产品经理，在行业通用产品的设计过程中普遍的思考逻辑。
在对市面上成熟的物联网平台产品进行使用和分析后，我们可以发现，虽然与低代码工具有一定差别，但物联网平台要实现其灵活性，贯彻低代码的理念是非常重要的。
面对复杂多样的物联网设备，现行的通用且先进的解决方案是将具有同一类功能的设备定义为一个产品，之后为这个产品匹配物模型。物模型在物联网平台中也是一个重要的概念，受篇幅限制，本次只进行简单介绍，后续有机会我们可以详细拆解。
当我们把同一类功能相同的设备集合成一个产品后，对产品物模型的定义，要从三个维度进行，分别是属性、服务和事件。
物模型定义好以后，相当于在物联网软件平台上构建好了相关设备的虚拟数字化实体，该虚拟实体实时映射实际设备，而我们接下来在搭建应用时，如设备台账、设备巡检、组态可视化、逻辑编排等，可以直接面向已经设置好物模型的虚拟数字化实体进行操作。所谓数字化的第一步——数据采集，我们也算踏过了其中一个门槛。
本文由 @点维数智空间 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。