在开始写代码之前：我们一定会先问客户的 5 个问题

很多系统项目，一开始就从“答案”出发。

“我们需要一套系统”
“我们想要一个数据看板”
“能不能把软件和设备连在一起？”

在 Simplico，我们通常会刻意放慢这一刻。

并不是因为我们不擅长开发系统——恰恰相反。
而是因为我们的经验告诉我们：

过早开始写代码，是系统建设中成本最高的错误之一。

在讨论系统架构、数据库设计或硬件集成之前，
我们一定会先从 5 个基础问题 开始。

这些不是技术问题，
而是帮助把事情想清楚的问题。

目的是避免：
系统“做得很对”，但方向从一开始就错了。

问题一：这个系统，究竟要让哪一个“决策或动作”变得更容易？

大多数需求描述的是“功能”，
而我们关注的是“决策”。

看板不是目标，
接口不是目标，
自动化本身也不是目标。

真正重要的是：

现在有哪些决策是慢的、不稳定的、依赖个人经验的？
谁在做这个决策？
如果决策延迟或出错，会带来什么影响？

好的系统，能让决策变得自然、顺畅。
不好的系统，只会增加页面和复杂度。

问题二：如果没有任何软件，这个问题还存在吗？

这个问题往往会让会议短暂停顿，
而这通常是一个好信号。

假设明天没有系统、没有程序：

问题还在吗？
这是流程问题、沟通问题，还是责任划分的问题？

因为软件只会放大现实：

清晰的流程 → 更高效率
混乱的流程 → 混乱被快速放大

在不依赖软件的情况下理解问题，
才能设计出真正“稳”的系统。

问题三：数据从哪里来，又到哪里去？

在涉及制造、设备、多部门协作的系统集成中，
问题往往不在代码，而在于边界不清。

我们会一起梳理：

数据由谁产生（人、设备、外部系统）
中间经历了哪些变化
在哪里变成决策、报表或行动

这样才能判断：

哪些地方适合自动化
哪些地方应该由人来控制
哪些场景下真的有必要接入硬件

好的系统尊重边界，
差的系统试图把一切揉在一起。

问题四：未来 2–3 年，哪些部分一定会发生变化？

大多数系统不会立刻失败，
而是在业务变化时，悄悄变得不适用。

我们会重点讨论：

哪些部分相对稳定
哪些部分可能变化（规模、法规、客户、设备、市场）

这直接影响设计决策：

哪里要避免硬编码
哪里应该配置化
如何在设备升级时不推翻整个系统

灵活性不是“什么都准备”，
而是选对需要灵活的地方。

问题五：你如何判断，这个系统“真的在发挥作用”？

不是在方案里，
也不是在 KPI 表格中。

而是在日常工作中：

哪些事情变简单了？
哪些沟通不再需要反复解释？
哪些日常烦恼消失了？

如果系统的成功很难用一句话说明，
往往意味着它过于复杂。

我们在咨询中常用的决策思路

下面是我们在前期沟通中，常和客户一起画的简化决策流程。

flowchart TD
  A["业务问题 / 目标"] --> B{"这是一个决策问题吗？"}

  B -- "是" --> C["谁在做决策？"]
  B -- "否" --> D["先优化流程 / 责任划分"]

  C --> E["缺少哪些信息？"]
  E --> F{"是否可以不靠软件解决？"}

  F -- "可以" --> G["流程 / 规则优化"]
  F -- "不可以" --> H["设计系统边界"]

  H --> I["以软件为中心进行设计"]
  I --> J["仅在有价值时集成硬件"]