写第一行代码之前就要写明需求
采购标的要在任何人看到可运行的界面之前就写清楚。同一份文件既要足够详细，以便据此与承包方结算；又要足够开放，以便在工作进行中还能修改。
公共部门
在这个行业，采购系统的方式有时与系统本身一样，由法规详细规定。
公共管理部门使用的系统，往往比身边的人员和技术存续得更久，并且要服务每一位前来办事的人。这里的变革要通过政府采购程序进行：在第一个界面出现之前就要写明范围，按文件验收，并要求承包方离开后，关于系统的知识仍留在机构内部。
在这个行业，我们有一个自己的案例：为波兰公共部门客户实施的JIRA定制，以及人力资源、IT和法务流程自动化。这就是我们在公共管理领域的全部经验，下方展示的也只有这一个。
行业主要挑战
不能关停的系统
各类登记系统和业务系统的运行时间，比周围一代又一代的技术都要长，而且通常不能停机。因此，变革只能在现有系统旁边进行，并且从第一天起就要与之对接。
一件事务同时经过多个系统
同一件事务涉及多个登记系统、多个科室和多个分别运行的系统。“这件事办到哪一步了”这个问题，有时比事务本身的处理更难回答，因为答案要从多个来源手工拼合。
界面面向所有人，而不是大多数人
公共机构无法挑选服务对象。它要服务每一位前来办事的人，并对这种接触的数字无障碍负责。因此，无障碍是系统的功能需求，而不是最后才补上的一层。
关于系统的知识必须留在机构内
双方的人员都会变动，而系统会一直存在。文档、运维以及由他人接手工作的实际可能性，都是采购内容的一部分，而不是承包方的善意。
我们如何提供帮助
投资之前先做诊断
我们从现状（as-is）审计入手：哪些系统真正在发挥作用，数据存放在哪里，维持现状需要多少成本。成果是一份附有预算量级的路线图，而不是一份关于转型的演示文稿。讨论首先关注哪些事项可以推迟或简化，而不只是哪些值得购买。
技术咨询分散系统的集成
计费结算、资产台账、空间信息系统和控制系统之间，如果没有中间层，很少能够互通。我们构建集成和运营门户，把这些数据源汇聚成运营团队可用的统一视图。集成层的设计确保即使没有我们，也能对其进行运维。
系统建设基于企业知识的人工智能
语言模型基于法规、文档和工单历史数据库运行，信息来源可控，每个答案都可追溯出处。这正是我们目前为一家大型能源集团提供服务的方式。无法核查、无法说明依据的模型，不会进入生产流程。
数据与人工智能内置于系统的合规
KSC审计准备、信息安全管理体系（ISMS）建设和内部制度制定，均与技术团队协同推进。各项要求作为验收标准列入待办事项（backlog），而不是写进单独的文档。审计轨迹在系统运行过程中生成，而不是事后补做。
合规与风险云或自有机房
部分数据不能离开客户的基础设施，这是出发点，而不是例外。我们在设计架构时，确保数据留在法规要求的位置：欧盟境内，或客户的基础设施内。无论目标环境如何，都使用同一套代码和同一套变更发布流程。
云与基础设施我们在该行业的项目经历
来自该行业
为该行业客户完成的一个案例，完整呈现。
JIRA定制与人力资源、IT及法务流程自动化
一家公共机构用一套贴合其工作方式的工具处理人事、IT和法律事务。
公共部门系统与集成
其他行业的项目经历
我们可迁移到这里的能力
来自其他行业的项目，其核心是技术而非行业领域。每个项目都标注了来源行业。
来源制造与贸易
企业内网与知识管理
一家制造和贸易企业有了集中管理知识、文档和内部沟通的统一入口。
系统与集成
来源银行、金融与债务催收
ERP、CRM、OCR与催收自动化
一家催收企业自动处理案件：系统识别文档，并打通ERP和CRM的数据。
系统与集成自动化与人工智能
来源电信
面向可扩展性的基础设施监控重构
一家美国互联网服务商用能跟上网络增长的系统监控基础设施。
系统与集成云与基础设施
来源银行、金融与债务催收
客户与营销活动数据整合
一家欧洲金融机构在同一处查看客户和营销活动数据，而不是分散在多个来源。
自动化与人工智能
来源银行、金融与债务催收
集团内JIRA的全球部署与标准化
一个多元化银行集团的各公司使用同一工具、遵循同一标准，而不是各自为政。
技术咨询系统与集成
来源未归入行业
实时遥测与网络ETL
一家美国云和安全企业实时分析网络流量，而不是事后处理。
自动化与人工智能云与基础设施
来源未归入行业
Azure上的工作流系统迁移与自动化
一家欧洲企业在Azure云中运行案件流转，系统运维不再需要人工。
云与基础设施系统与集成
来源银行、金融与债务催收
Web应用的DevOps与CI/CD自动化
一家欧洲银行自动发布应用更新，无需人工构建和发布版本。
云与基础设施系统与集成