郑浩然：

始于问题而非技术

在华尔街日报畅销书《麦肯锡讲全球企业数字化：AI时代赢得竞争优势的数字化操作指南》之中，作者Eric Lamarre曾有过这样的论述，一切成功的数智化转型必然始于问题，而非技术。「永远从想要解决的业务问题开始」是数智化系统建设甚至是「数智+AI」升级强化的逻辑关键。

在天津市眼科医院视光中心的数智系统——信息化综合管理平台的建设也曾经历过在「自研」与「购买」之间的「选择纠结」。在普遍的认知中，「成品系统」具有产品化的优势，其大致可以总结为两点：一个是因规模化验证后而积累的「功能普适性」，另一个是专属团队专注开发和维护的「稳定性」。换句话说，「买来主义」也许是最为「省时省力」的方式，而「自研之路」却会是一条坎坷且悠长的路。

然而，在我们广泛地对市场上的相关「产品化系统」进行调研后却发现，因为视光行业的运营变量和颗粒「细碎程度」远超过于大多数普世认知中标准。所以，因为没有人潜心去做视光行业的「量体裁衣」，故而也就自然没有「紧致合身」的产品可选。而随着需求分析的深入，天眼视光的技术团队逐渐意识到，要打造一个真正适合视光中心的综合服务及管理系统，项目建设者必须从行业的特性出发，深入挖掘其独特的运营规律和业务需求，既做「局外人」，又是「局内人」。由此，「自主研发」就成为唯一可选的那条路线。

既已选择「自主研发」，那么摆在眼前的运营痛点就必须通过系统的接续建设来解决，而系统建设又分为前面所说的数字化、数智化、数能化这三个阶段。首先，在数字化阶段，全员统一思想、达成共识、全情投入，这是攻坚闯关的基础。直到现在我们还记得，在天眼的数字化阶段，中心的各级管理层冒着疫情的挑战，在总部的报告厅中度过了不知道多少个不眠夜，大家用「白纸黑字」和各类图表把运营的所有流程逻辑化、关联化、全局化。在「贴满墙壁」的思维共创中，所有人都为这件从来未曾做过的事而「绞尽脑汁」，同时也都在这番历练中「脱胎换骨」。而最终，天眼数智化的系统就是通过这样的方式一字一句，一点一滴的汇聚而成，最终成为一串串构建系统的代码和算法。在数智化阶段，系统建设需要集中解决的问题主要聚焦在「人、货、场的三位协同」、「医疗诊程管理与商品流转的相互协同」以及「细碎的品类与供应链敏捷性的相互协同」，而「协同」的意义就在于找到多方兼顾的「黄金结合点」，从而将其变为系统中的流程逻辑关系。这些逻辑关系不是「为系统而生」的逻辑因果，而是「因运营而生」的管理智慧。换句话说，数智化的过程并不是考验「技术水平」的一个过程，更多的是验证管理水平的一个过程。这也是为什么天眼视光的自研管理系统在问世之后会引来行业各界的关注，因为技术在其中只是「故事的语句」，而天津眼科的管理经验才是「故事的精髓」。

当数智化系统雏形问世之后，项目本身远没有结束，更准确地说，这个时候项目才是实践意义上的「刚刚开始」。在这里，容许探索与试错，重视彼此包容的组织文化是支撑数智化系统「有机生长」的「肥沃土壤」。

所谓「有机生长」，其中包含了两层意思。第一层的「有机」是系统本身的「有机」，简单而言就是系统根据问题而建设，同时也会根据新发生的问题而进行改良。第二层「有机」，是人与人之间协作的「有机」，在这个层面，因为自研团队和职能部门本就是「一家人」，所以「一家人不说两家话」的试错、容错、共创改进和持续迭代就变得更为「丝滑」。这些「有机生长」的过程不仅考验着团队的技术能力，更考验着团队成员的心理素质和协作精神。只有当研发团队和运营团队能够并行不悖、相互融合之时，「群智的力量」才能真正将技术融入到管理之中，形成数智化转型场景中的核心能力。

顺应着上述的思维主线，我们也不难总结出这样的一番定义——真正的数能化，也可能被分为两个层次。一方面是将数智化系统实现的能力价值赋能于员工；而另一方面，至少在天津市眼科医院视光中心，则可能是通过自研开发的数智化历程，实现一种「全员具备」的数智化思辨和研发的素养。而后者的长远意义在于，在数智化已然不是一个信息工程项目而是成为管理必不可少的管理手段时，只有全员具备数智化研发和思辨的素养，企业才有可能持续不断的进行数智化迭代。

始于问题而开发的每一个模块，终将构建成为一个全局性的系统。然而，如何让「根据问题而开发」的一个又一个模块，具备最终整合成一个综合系统的能力？在天眼视光，我们的答案是：开槽。在总体蓝图中，理想的天眼视光数智化管理平台包括数据底座、业务中台和交互终端。然而「大厦必然不可能一日建成」，系统也不能等到全面建成的那一天再谈使用。因此，为了同时满足整体蓝图和运营的阶段性需求，模块化的设计理念就变得极为重要，即将系统分解为多个独立而又相互关联的子模块。每个子模块都应该具备清晰的职责和定义良好的接口，以便在需要时可以轻松地进行替换、扩展或升级。而这些「接口」的建设，我们给了它一个独特的技术称谓：开槽。

如果用技术语言来解释「开槽」，我们可以把它理解成为一种具备灵动弹性的「微服务架构」。微服务架构允许我们将一个大型的应用程序分解为一组小型、独立的服务，每个服务都围绕特定的业务功能进行构建，并通过轻量级的通信机制进行交互。这种架构不仅有助于提高系统的可维护性和可扩展性，还能在一定程度上降低开发和部署的复杂性。

而在微架构的「背后」，必须有一个精心构建的、具有强大功能的数据管理平台。这个平台要能够处理各种类型和规模的数据，并提供高效的数据存储、查询和分析功能。通过采用前沿的数据处理技术和工具，我们可以确保系统在面对海量数据时仍能保持高性能和高可用性。换句话说，就是让软硬件相结合的「肌肉」可以根据任务「弹性发力，收放自如」。

以预先「开槽」的「微架构」为「骨骼」，以「数据管理平台」为「脏器」和「血脉」，数智化系统的「生长功力」还将取决于其面对持续优化和升级的需求时的「感知力」和「反应力」。对此，一个多维度的反馈机制必不可少——通过收集和分析用户反馈、系统日志和性能指标，运维和开发的伙伴们可以及时发现并解决潜在的问题，递进式的改进系统的功能和性能。并且「时刻准备着」，向系统注入新的行业要求和可应用的前沿技术，从而让「系统」的「有机生长」不断满足管理和运营所面临的新的挑战。

总之，在建立「微架构」时，怀着「扫天下」之心，去「扫一屋」；面对优化和升级时，践行「积跬步而成千里」，这或许就是天眼视光开发之路上的「知行合一」吧。

李鸣瑞：

让系统运维深度嵌入业务管理

从数智化大系统和全过程之中「以管窥豹」，运维必定是平行于「有机研发」的重要「一斑」。通常意义上讲，运维工作是确保整个有机体正常运行的关键保障，它涉及到多个「褃节儿」方面，包括但不限于问题应对、预防性处理、定期巡检以及特殊情况下的紧急处理。具体来说，运维团队需要「 时刻待命」准备应对各种突发问题，确保系统的稳定性和可靠性。同时，从经验中总结可以防患于未然的「预处理」策略，则是「（Trouble Shooting）问题射击」之外的「上游努力（Upstream Effort）」。最后，运维团队的管理中，「尖刀机动队」的建设和功效则更为不容小觑，所谓「尖刀机动队」就像特警中的「SWOT」，即是将运维和开发团队中的「高手」和「强手」组织起来，进行系统性的操练，并配以不定期的「演练」，专以在面对紧急系统问题时，特勤攻坚。

那么，如何去辩证的思考运维与开发的关系？当然，毋庸置疑，运维与开发的紧密结合是确保业务连续性和系统稳定性的基石。其中，运维团队通过实时监测系统运行状况，能够及时捕捉潜在的故障源和性能瓶颈，并据此收集和锁定问题（流程逻辑的错误和不畅）和BUG（系统运行的错误和不畅）。而这些问题和BUG 的解决会交错于两条路径去解决，一条路径是系统更新，而另一条路径是系统升级，即Update（更新）和Upgrade（升级）。

尽管Update和Upgrade这两个词在日常使用中常常被混用，但它们在技术层面上有着明显的区别。理解这两个概念的不同之处，对于确保系统稳定运行和提升系统性能具有重要意义。首先，Update（更新）通常指的是对系统或软件进行小幅度的修补和改进。这些修补主要是为了修复已知的漏洞、错误或缺陷，以确保系统的安全性和稳定性。更新操作一般不会对系统的功能和架构产生重大改变，而是通过打补丁的方式，对现有系统进行微调和优化。例如，操作系统或应用程序发布安全补丁，修复已发现的安全漏洞，这就是典型的Update操作。

另一方面，Upgrade（升级）则涉及到对系统或软件进行较大幅度的改进和功能增强。升级不仅仅是修复已知问题，更多的是引入新的功能、改进用户界面、提升性能或扩展系统兼容性。升级操作可能会涉及到更换或增加新的硬件设备，或者安装新的软件版本，从而使得系统在功能和性能上都有显著提升。例如，将旧版本的操作系统升级到最新版本，或者将数据库管理系统从一个较旧的版本升级到一个较新的版本，这些都是Upgrade的典型应用场景。

如果我们要将团队中运维和开发的职责和功能进行区分，那么Update（更新）更多关注于修补和优化现有系统，这一部分工作倾向于被归纳为运维范畴的「主攻方向」。而Upgrade（升级）则侧重于引入新的功能和改进系统性能，这部分工作或许可能更多的被纳入为开发团队的「主攻方向」。然而，正如前面所提到的，因为「系统更新」与「系统升级」之间存在着很强的「交错性和混合性」，所以运维与开发之间也势必存在着「你中有我，我中有你」的「交错性」。因此，「运维」和「开发」，「更新」和「升级」就像是电的正负极，只有运维与开发紧密协作，交错递进，整个数智化技术团队才能将系统的「生长力」推进至「最佳状态」。而这些，或许就是当代视光企业自研数智化的一套屡试不爽的「辩证法」。

最后，也是运维中最重要的一点——让系统运维深度嵌入业务管理的「一把钥匙」就是「服务之心」。实际上，正如前文中反复提到的，当下和未来的视光企业数智化，已经不是一个或几个「软硬件引进项目」，它是一场旷日已久，接续延伸的，以技术为推手，以运营管理为灵魂的管理变革。因此，在这场变革中，所有参与者既是研发者，又是管理者。

如果这个思路能够引起共鸣，那么对于置身其中的数智技术团队而言，每一个成员都必须具有管理者、运营人和技术人的多重身份。他们将不再是「IT人」、「程序员」或是什么其他，他们就是管理团队和运营一线的一员，他们就是以数智专业来创造视光运营价值的运营工作者。

而在天津市眼科医院视光中心，正因为所有人皆「风雨同舟」，一起走过到了从数字化、到数智化再到求索数能化的「自研之路」，所以数智技术团队与其他部门、其他伙伴们的结合才变得超乎寻常的紧密，彼此之间的包容与契合才能做到接近「零距离」的状态。这或许正是除系统本身之外，「自研」的抉择带给天眼视光的另外一个价值连城的成就。

在后场服务前场、前场服务顾客的简单逻辑下，一切的协作纷繁皆以「服务之心」化繁为简，一切的细分目标皆以「创造客户」统为靶心。如果说，天眼视光的数智化历程值得借鉴并小有所成，那么坚持以服务之心创造客户或许便是这场数智化征程演绎中的「精神算法」。