寫第一行程式碼之前，先要寫好要求
採購標的要在任何人看到可運作的畫面之前寫好。同一份文件既要足夠詳細，以便據此與承辦商結算；又要足夠開放，以便在工作進行期間仍能作出修改。
公共部門
在這個行業，採購系統的方式，有時與系統本身一樣由法規詳細規定。
公共行政機構使用的系統，往往比身邊的人員和技術存在得更久，並服務每一個與其打交道的人。在這裏，變更要經公共採購程序推行：在第一個畫面出現之前已訂明範圍，按文件驗收，並要求承辦商離開後，有關系統的知識仍留在機構內。
我們在這個行業有一個自家案例：為波蘭公共部門客戶進行JIRA定制，並把人力資源、資訊科技和法律流程自動化。這就是我們在公共行政方面的全部經驗，下文亦只列出這一項。
行業的主要挑戰
不能關閉的系統
登記冊和業務系統的運作時間，比周邊一代又一代的技術更長，而停用它們通常不在考慮之列。因此，變更只能在現有系統旁邊推行，並由第一天起便要與之互通。
一宗個案同時經過多個系統
同一宗個案涉及多個登記冊、多個組別和多個各自運作的系統。「現在處理到哪個階段」這個問題，有時比作出決定本身更難回答，因為答案要以人手從多個來源拼湊。
介面是為所有人而設，不只為大多數人
公營機構不能挑選服務對象。它服務每一個與其打交道的人，並要為這些接觸的數碼無障礙負責。因此，無障礙是系統的功能要求，而不是最後才加上的一層。
系統知識必須留在機構內
雙方的人員會更替，系統卻會留下。技術文件、維護，以及由他人接手工作的實際可能，都是採購的一部分，而不是承辦商的好意。
我們如何協助
投資前的診斷
我們先檢視現況：哪些部分真正有效運作、數據存放在哪裏、維持現狀要花多少成本。成果是一份附有預算量級的路線圖，而不是一份關於轉型的簡報。討論先從哪些可以延後或簡化開始，而不只是哪些值得購買。
科技顧問整合分散的系統
計費、資產登記、地理空間系統與控制系統，沒有中間層便很少能互相溝通。我們建構系統整合與營運門戶，把這些數據來源匯聚成營運團隊可用的單一視圖。整合層的設計，讓客戶即使沒有我們也能自行維護。
系統建構以企業知識為基礎的人工智能
語言模型建基於法規、文件及工單歷史資料庫，設有來源控制，並記錄每個答案的出處。我們目前正以這種方式為一家大型能源集團工作。無法核實及說明理據的模型，不會進入生產流程。
數據與人工智能內建於系統的合規
為波蘭《國家網絡安全系統法》（KSC）的審核作準備、建立資訊保安管理系統（SZBI）及制定內部規章，均與技術團隊一同進行。各項要求以驗收準則的形式進入待辦清單（backlog），而非另寫一份獨立文件。審計軌跡在系統運作期間產生，而非事後重建。
合規與風險雲端或自有伺服器機房
部分數據不能離開客戶的基礎設施，這是我們的出發點，而非例外。我們設計架構時，確保數據留在法規要求的位置：歐盟境內，或客戶的基礎設施內。無論目標環境為何，都沿用同一套程式碼和同一套變更發佈流程。
雲端與基礎設施我們在這個行業的往績
來自這個行業
為這個行業一位客戶完成的案例，在此完整介紹。
JIRA定制及人力資源、資訊科技和法律流程自動化
一家公共機構以一套貼合其運作方式的工具處理人事、資訊科技和法律事務。
公共部門系統與整合
其他行業的往績
我們帶到這個行業的能力
來自其他行業的項目，重點在於技術而非行業知識。每個項目都註明所屬行業。
來源製造與貿易
內聯網與企業知識管理
一家製造及貿易公司以同一處集中知識、文件和內部溝通。
系統與整合
來源銀行、金融與債務追收
ERP、CRM、OCR與債務追收自動化
一家債務追收公司自動處理個案：系統識別文件，並連接ERP和CRM的資料。
系統與整合自動化與人工智能
來源電訊
為提升可擴展性重構基礎設施監察系統
一家美國互聯網供應商以能跟上網絡增長的系統監察基礎設施。
系統與整合雲端與基礎設施
來源銀行、金融與債務追收
整合客戶及推廣活動數據
一家歐洲金融機構在同一處查看客戶和推廣活動的數據，而非分散於多個來源。
自動化與人工智能
來源銀行、金融與債務追收
在集團內全球推行並統一JIRA
一個多元業務銀行集團的各公司以同一工具、同一標準工作，而非各自為政。
科技顧問系統與整合
來源未歸入行業
實時遙測與網絡ETL
一家美國雲端及保安公司即時分析網絡流量，而非延後處理。
自動化與人工智能雲端與基礎設施
來源未歸入行業
在Azure遷移並自動化工作流程系統
一家歐洲公司在Azure雲端處理個案流程，系統運作不再需要人手。
雲端與基礎設施系統與整合
來源銀行、金融與債務追收
網絡應用程式的DevOps與CI/CD自動化
一家歐洲銀行自動發佈應用程式更新，無需以人手建構和發佈版本。
雲端與基礎設施系統與整合