可以提出什么要求，并不总是一目了然。我的工作从一个问题开始：我们期待怎样的结果。
组织往往说不清自己想要什么，因为不知道有哪些可能。点名要某个具体系统，往往只是最初的想法，而不是目标。我会先问目标和成功的定义，有条理地引导分析，然后才选择工具。对市场和现有解决方案的了解，是我最大的专长。
我首先提出的问题
- 您设想中理想的未来是什么样子？
- 今天有什么让您困扰？
- 我们为什么要做这件事？
- “完成”的定义是什么（definition of done）？
- 依据哪些标准，我们才能认定这个项目取得了成功？
很少有组织会问自己这些问题。它们通常直接去找一家看起来有“对应系统”的公司。这恰恰是浪费时间和金钱的捷径。一位对市场有广泛了解的外部顾问会把握航向、提出正确的问题，并引导组织走上对它自己最有利、而不是对供应商最有利的道路。这样，您就能在采购任何东西之前避免失误、降低风险。毕竟，我们真的清楚EZD（波兰公共机构的电子公文系统）、ECM、案件管理（case management）、DMS、工作流（workflow）和BPM之间的区别吗？
- 案件与公文流转工作流（workflow），适用于审批路径和决策留痕至关重要的场合
- No-code, low-code, pro-code当流程具有自身特点、并且会不断变化时
- RPA当需要集成、却没有标准接口可用时
- AI从分析型AI、生成式AI，到经过编排的智能体系统
- 文档管理系统DMS，因为有时这就足够了
- ECM与案件管理用于管理各类内容和案件的企业级系统
- CRM / SRM以流程为导向、多渠道地管理与客户、供应商和利益相关方的关系
- 调整流程规定当实现目标并不需要新系统时
- 公共部门与职业自治团体沿袭纸质时代、出于惯性延续的流程。先描述现状，再看可以提出什么要求。
- 市政公用企业“一套适配KSeF（波兰国家电子发票系统）的发票系统”，而背后真正需要梳理的是采购政策。
- 企业“我们需要CRM”，而实际需要的是以流程为基础的客户与报价管理。
我带来市场知识、20年的项目经验、设计思维、结构化解决问题的能力，以及对供应商真实意图的了解。目的是让数字化更简单、更省钱，让您的项目不会重蹈那些项目的覆辙：它们耗费了数十万乃至数百万兹罗提，而原本从一开始就可以换一种方式推进。
我并非无所不知，但我清楚自己知识的边界在哪里。我也能看出组织自身还不知道什么。遇到这种情况，我会请合适的专家加入团队，陪您渡过这一关；而如果没有顾问，组织往往意识不到自己需要这样的专家。
-
IT系统与流程盘点
我们究竟有什么？
这是每一项实施决策的起点。在您选择系统、供应商或方向之前，先对自己已经拥有的一切形成清晰、有条理的认识。
- 应用清单，包括负责人、合同、许可证、成本和支持终止日期。
- 有系统支持与无系统支持的流程图，集成关系图，以及数据需要手工重复录入的环节。
- 风险登记册，包括单点故障和对供应商的依赖（vendor lock-in）。
- 系统A/B/C/D分类，以及一页纸的管理层摘要。
2–6周，低于公共采购门槛。
IT系统盘点的完整范围 -
需求分析与研讨会
我们真正需要什么？
通过内部研讨会，我们一起厘清组织真正需要什么。我常常用简单的问题把它挖掘出来：成功的定义是什么？这个项目在什么时候会被认为是成功的？企业和公共机构常常跳过这一步，要么以为自己什么都清楚，要么根本没有时间深入追问。这正是项目出问题最常见的原因之一。
- 与管理层以及日常在流程中工作的人员共同开展研讨会：目标、期望、限制条件。
- 成功的定义，以及判断项目是否奏效的标准。
- 描述当前的痛点，以及未来应有的样子。
- 为编写需求或开展市场调研提供依据，或者得出无需新系统的结论。
-
数字化战略与目标架构
我们去往何处，按什么顺序？
这是一份不会被束之高阁的战略，因为它建立在组织实际拥有的基础之上，并指明下一个预算周期该做什么。
- 分层构建的目标架构：登记库、流程、集成和访问。
- 组织采纳的标准：权限模型、接口标准、需求文档编写规则。
- 区分法规义务与投资的路线图。
- 系统采购的采购规则，以及区分投资与运维的预算。
-
需求与项目准备
如何描述需求，才能让供应商理解？
在您发起招标或发出询价之前，用您自身流程的语言写成需求。有了它，各家报价才具有可比性，日后也能据此追究供应商的责任。
- 访谈、流程图、数据模型、集成和测试场景。
- 最重要的是回答：怎样才算实施成功，也就是我们为什么做这件事、期待什么结果。
- 当管理层有想法却没有时间写成文字时：只需一次谈话，约2天内即可拿出概念方案或原型。
-
报价评估与供应商沟通
如何有效比较不同供应商的报价？
这是一份独立意见，与您自己IT团队的建议并列，而不是取而代之。管理层得到一份可以据以决策的比较，并且能在地方议会、所有者或集团总部面前站得住脚。
- 向供应商提出的问题，以及基于您自身场景的演示。
- 比较矩阵：将各份报价统一到相同范围，多年期总成本，运维条款和合同退出条款。
- 对于子公司，按总部采购准则进行比较，必要时使用英文。
- 作为采购方代表参加与供应商的会议。
-
实施、变革与验收
如何让项目落地、说服员工，并让供应商履约担责？
大型IT项目同时也是一场工作方式的变革。它往往是您组织里的第一次，但在我的职业实践中并非第一次。我在实施团队中代表管理层，并引导变革，使员工真正接受新系统。只有在需要作出决定时，管理层才需要重新介入。
- 把控范围、进度和变更决策，并建立变更与决策记录。
- 变革管理：沟通计划、培训、各部门的变革推动者，以及与尚未被说服者的沟通。
- 简短摘要，供管理层使用，也用于与IT部门、地方议会或集团总部沟通。
- 按照约定的测试场景和标准进行验收，数据迁移经过核验。
- 运维合同不会让您对单一供应商的依赖超出必要程度。
-
管理层常任顾问
我们没有IT总监。谁来统筹全局？
这一角色在国际上被称为“兼职CIO（fractional CIO）”，区别只有一点：我不接管IT部门，也不接管其预算。我把管理层的意图转化为需求，评审IT部门的建议，并在与供应商的往来中代表采购方的利益。
- 每月与秘书长（行政负责人）或总经理以及IT负责人会面一次，每月提交运营与风险报告。
- 每季度审查风险和关键合同，重大采购前出具意见。
- 最初90天：初步摸底并识别紧迫的“危险信号”，建立各类登记册并启动合同审查，向管理层提交附12–24个月路线图的报告。
每个阶段需要多长时间，取决于组织和项目：组织的准备程度、组织文化，以及管理层给予的授权。因此，范围和时间安排在首次洽谈后确定。只有IT系统盘点有固定的价格和周期。
能为决策护航的演讲。面向管理层、监事会以及更广泛的决策群体。
顾问不仅要提出正确的问题，还必须能够在作出决定的机构面前，为所采用的假设、报告和项目成果进行辩护。当您需要一场能说服利益相关方的专业演讲时，我可以带来至少126场会议演讲的经验（主要在波兰，也包括美国和爱尔兰），以及在管理层、监事会和更广泛场合作汇报的经验。我用决策、风险和资金的语言来呈现技术。
- 向管理层或监事会推荐项目：现状、备选方案、成本和风险。
- 在更广泛的决策者面前为报告及其成果辩护，包括应对尖锐的提问。
- 在会议或行业论坛上介绍项目构想及其成果。
演讲主题：信息管理与流转、协同办公、电子商务、系统架构与集成、用户体验，以及面向地方自治政府的行业会议。
同一条航线，三个不同的出发港。
每个群体的出发点是不同的问题，但从信息混乱走到一个站得住脚的决策，路径是相同的。
在选择阶段之前。
我们如何开始合作？
从一次30分钟的免费洽谈开始，谈谈您面前的决策。第一步通常是IT系统盘点，因为之后的每个阶段都以其结果为基础。如果决策已经作出，或者项目已在进行中，也可以从您所处的阶段开始。
可以只委托一个阶段吗，比如报价评估？
可以。航程中的每一点都是一项独立的服务。我从较小的范围开始，当双方都认为有意义时再扩大范围。
每个阶段的费用和周期是多少？
IT系统盘点需要2–6周。其他阶段的范围、时间和价格在首次洽谈后确定，因为它们取决于组织、项目、团队的准备程度以及管理层给予的授权。