# 独立IT顾问：ERP选型与实施 | Krogis

Źródło: https://krogis.pl/zh/biznes
Język: zh
Opis: 您有项目，而IT团队忙于日常运维。ERP或其他系统的需求、供应商选择、实施监督与验收——站在管理层一方。

---

# 新系统只是项目的一半。 *另一半是人。*

Krogis为外国集团子公司和企业的管理层提供咨询，适用于有项目要推进、而自家IT部门忙于运维的情形。新ERP的选型与实施、投诉处理、流程驱动的CRM、适配KSeF（波兰国家电子发票系统）的费用单据流转、合同管理、员工入职与离职：我与管理层一起梳理需求，与您的IT团队和供应商沟通，比较各方报价（在子公司中对照总部采购准则），就项目实施的监督提供建议，并帮助大家为工作方式的变化做好准备，让员工在系统上线后真正用起来。 **只需一次谈话，约2天即可拿到概念方案。**

[预约沟通](mailto:wojciech.kroczak@krogis.pl?subject=%E5%85%B3%E4%BA%8E%E6%96%B9%E6%A1%88%E7%9A%84%E6%B2%9F%E9%80%9A) [查看已完成的案例](https://krogis.pl/zh/biznes#przyklad)

**细部 1** 工程师桌上的零件 **比例 1: 1** 示意图片 **图纸 1** 企业

## 企业里的变革管理。 *典型项目，以及它们给人们的工作带来哪些变化。*

在企业里，推动变革的通常是业绩，或者总部的决定。当员工明白这对自己意味着什么，就会更快接受。

### 实施ERP或CRM

**对人来说有什么变化：** 销售、财务和客户服务在共享数据上工作，而不是各用各的表格。

**常见难点：** 急于见效的压力，加上Excel用着顺手：如果新系统从第一天起不比表格更方便，就会输给表格。

**我关注的重点：** 让部门负责人成为第一批用户，从第一周起衡量系统使用情况，上线后进行复盘。

### 流程平台与工作流

**对人来说有什么变化：** 申请、审批和投诉沿着一条统一、透明的路径流转，而不再靠邮件和电话。

**常见难点：** 每个部门都有自己的例外情况，都希望系统把它们全部照搬进去。

**我关注的重点：** 先描述流程，与各部门负责人商定例外，再上系统。

### 在子公司落地总部的决定

**对人来说有什么变化：** 子公司接手总部选定的工具或流程。

**常见难点：** “这不是我们的主意”：总部的目标不会自动变成本地团队的理由。

**我关注的重点：** 把总部的目标转化为子公司员工能感受到的具体好处，并明确本地由谁对变革负责。

### AI智能体与自动化

**对人来说有什么变化：** 一部分重复性工作交给自动化完成，人负责核查结果、处理例外。

**常见难点：** 担心丢掉工作，以及把没有梳理清楚的流程自动化，结果只是让混乱来得更快。

**我关注的重点：** 先描述和理顺流程，明确责任规则，再上自动化，同时坦诚地谈清楚各个角色会有哪些变化。

**KSC与NIS 2。** 如果贵公司向受KSC约束的实体提供服务，客户会开始要求在合同中写入相关条款并提供证明。我帮助准备答复和文件，而无需另建一个安全部门。 [从管理层角度看KSC](https://krogis.pl/zh/uslugi/koordynacja#ksc)

[什么是变革管理，为什么值得投入](https://krogis.pl/zh/zarzadzanie-zmiana)

## 值得先有答案的几个问题。

这些问题，我会在大型实施项目启动之前，向董事会成员和财务总监提出。如果其中有哪一个的回答是“我们不知道”，那正是我可以帮上忙的地方。

1. **新系统上线之后，人们的工作究竟应当发生什么变化，我们又如何衡量？**
2. **我们这一侧，由谁把用户的需要转化为对供应商的要求？**
3. **我们是在统一的范围和总成本的基础上比较报价吗？**
4. **我们如何确保忙于运维的IT团队不被项目压垮？**
5. **当实施开始偏离管理层的意图时，我们怎么办？**

**出错的代价。** 不能满足员工需要的ERP实施，意味着许可、实施的费用，以及数月没有成效的工作。顾问的费用通常低于一项选错的技术、一家不合适的供应商，或合同中的一个陷阱。

## 您能获得什么。 *文件是工具，而非目的。*

- **管理层的时间** 15–20分钟的谈话，取代数周的研讨会。只在真正需要的地方做决策。
- **ERP及其他系统实施中更少的失误** 在选择供应商之前，先确定目标和成功标准。
- **按成果问责供应商** 可作为依据的需求、验收标准和变更记录。
- **真正使用系统的员工** 变革管理，并在各部门设立变革推动者，让实施不只停留在纸面上。
- **更低的投入** 与问题相匹配的工具——有时结论是根本不需要新系统。

**Wojciech Kroczak** 变革管理与数字化顾问。2017–2026年：一家外国集团旗下的工业子公司。2016–2026年：一家国际控股集团——银行、租赁、保险。

**致集团总部：** Krogis 是波兰子公司本地管理层的独立顾问。我能在两天内把与管理层 15 分钟的谈话变成一份方案，撰写 IT 团队和供应商可以直接据以执行的需求，对照集团采购准则比较各方报价，并在实施期间代表管理层。不销售软件，不隶属于任何供应商。如有需要，可提供一页英文摘要。

## 管理层有一项决策要做。 *却没有人有时间把它写清楚。*

管理层非常清楚要解决什么问题、要堵住什么风险——把这些说清楚只需要一刻钟，而不是一周的研讨会。

内部IT接到笼统的指示后，往往先召集会议、寻找现成方案——而此时还没有人写下真正需要的是什么。

没有概念方案或原型，就很难判断一个想法是否具有商业意义——“做还是不做”只能凭感觉决定，而不是基于具体的东西。

项目一旦启动，管理层要么被拖进根本没有时间参加的工作会议，要么反过来，无从掌握实施是否仍符合其最初的意图。

**如果贵公司已有一位经验丰富、进入管理层的CIO，这项服务并不适合您。** Krogis适合这样的企业：管理层深度参与日常运营，IT部门规模小，由IT技术人员而非管理者组成，且忙于日常运维——例如大型工业和金融集团的子公司、服务和保险公司，以及储蓄信贷合作社（SKOK）。

## 我们想买一把锤子， *因为……我们要挂一幅画。*

企业常常说不清自己想要什么，因为不知道可以提出什么要求。管理层说“我们需要买一套系统”，经过一连串追问——“这套系统用来做什么，你们想借助它达成什么，你们认为上线之后会发生什么？”——往往就会浮现出真正问题的定义：“我们想更快地处理投诉，更方便地做报表，降低成本，符合总部的要求，提高渠道A的销售盈利能力。”

我会询问目标以及怎样才算成功，并有条理地推进分析，直至找到真正的目标，它往往隐藏在最初对系统的设想背后。

1. 提出的要求“我们想买一套发票流转系统。” 实际需要 - 梳理整个采购政策， - 描述并优化从采购申请、订单和合同直到费用单据的各项流程， - 供应商管理规则。
2. 提出的要求“我们需要一套CRM系统。” 实际需要 - 理清交易对手数据的生命周期：交易对手何时、在哪些系统中登记，由谁负责，以及哪些业务事件发生时客户数据应出现在其他系统中， - 条理清晰、已数字化的报价流转程序， - 以流程化方式登记、更新和核实交易对手数据， - 便于准备报价的工具， - 营销自动化的途径， - 销售活动自动化的途径， - 监测与潜在客户及现有客户沟通中的情绪倾向。 一家集装箱码头。这并不是典型的简单CRM，而是对客户服务的流程化改进。
3. 提出的要求“你们有CRM的营销模块吗？” 实际需要 - 一个利益相关方关系管理工具，而不是又一个销售模块。

我会从企业很少问自己的问题开始：您理想中的未来是什么样子，今天是什么让您困扰，我们为什么要做这件事，怎样才算完成，以及依据哪些标准来判断项目成功。我们不急于找一家“有现成系统”的供应商，而是先确定目标。我能够描述和分析流程，但更重要的是引导分析与提问：在组织内部、在各项定义中，以及在与供应商的沟通中。这样您不会浪费时间，也能更快达到真正想要的效果。

## 实施系统时，谁负责什么。

投诉、费用单据流转、服务请求：无论哪个模块，机制都是一样的。

## 这是您的情况吗？ *首次交流之前，值得了解的四件事。*

### 常见的迹象

常常出现这样的情况：贵公司的IT忙于日常运维，而项目在等人来撰写需求。供应商有时会自己提出范围和进度计划。总部或集团询问进展，答复却要从多个来源拼凑。项目文档的形成参差不齐：并非总能说清谁是作者、谁是所有者，也不清楚是否已获批准。

### 推迟可能会怎样

范围可能因实施过程中提出的变更而扩大，成本和期限随之后移，验收则依据供应商的说法。此时新入职的IT人员进入项目时，没有经过整理的知识。

### 通常由谁担任发起人

多数情况下是管理层成员（CFO或运营总监），对实施的业务成果负责。

### 我不做什么

我不是供应商的项目经理，不对实施负责，也不对贵公司员工的工作进度负责，但我会协助监督这些方面：我做的是管理层往往抽不出时间做的事，即确保项目进展、责任分工以及需要决策的事项一目了然。

**最小而稳妥的第一步：** 一次30分钟的免费交流。根据与管理层15–20分钟的谈话，我大约在2天内准备出方案概念，不产生任何实施费用。

## 多个项目同时推进，而总部要看进展。 *谁来汇总？*

ERP实施、流程驱动的CRM、适配KSeF的单据流转、文档整理：IT部门负责维护系统，项目往往没有固定的协调人。此时管理层时间有限，掌握的情况也不完整。

我作为管理层一侧的常任协调人（在大型组织里称为PMO，即项目办公室）。一张统一的项目全景图，定期的进展通报和报告，也可为总部提供英文版。

- 项目清单：载明各阶段、期限、负责人、相互依赖和阻碍，并标注绿、黄、红状态。
- 每周或每两周一次的进展会议，附会议纪要、行动清单和期限。
- 风险、决策和文件登记册：谁是文件作者，谁是负责人，目前处于哪个审批阶段。
- 协调团队、任务负责人与供应商之间的信息，并在事情停滞时升级上报。
- 管理层仍是决策、预算和执行的负责方。我不接管实施的责任，只负责让进展清晰可见。

[项目协调与常态化秩序的服务范围](https://krogis.pl/zh/uslugi#doradca)

## 实施ERP或其他大型系统。 *管理层需要有人站在自己一边的四个节点。*

您的IT团队负责让一切日常运转正常。实施项目则是另一项工作：需要描述需求、选择供应商、开展谈判并核算成果。我可以参与其中某一个阶段，也可以与您一起走完全程。

1. **准备与需求 列出新系统要接管或替代的流程、系统、数据和集成。一位获得管理层授权的业务负责人，上线后需要验证的目标，以及用贵公司流程的语言写成的需求，而不是供应商宣传册上的功能清单。**
2. **选择供应商或实施合作伙伴 询价，基于贵公司自身场景的演示，统一到相同范围后在矩阵中比较的报价：数年期的总成本、团队、工作方式、运维条款和退出条款。**
3. **与IT沟通并监督实施 我在与供应商及贵公司IT团队的会议上代表管理层，把控范围、进度和变更决策。管理层收到简短的总结，只在需要其决策时才再次介入。**
4. **验收与结项 依据约定的测试场景和标准进行验收，经过核实的数据迁移，文档和培训。一份不会让您对单一供应商产生超出必要程度依赖的运维合同。**

所需时间取决于组织和项目：企业的准备程度、组织文化，以及管理层赋予项目的授权。因此，时间安排在首次沟通后确定，而不是写在价目表里。

### 实施前我常听到的问题

### 如何让企业为ERP实施做好准备？

在与供应商接触之前，先把现有情况记录下来：新系统要接管或需要与之协同的流程、系统、数据、集成和合同。任命一位获得管理层授权的业务负责人，并商定如何判断实施是否成功。决定哪些地方采用系统的标准流程，哪些地方您自己的流程是值得保留的竞争优势。用流程语言写成的需求，能帮助您比较报价，并在之后追究供应商的责任。一个好的起点是[IT系统盘点](https://krogis.pl/zh/inwentaryzacja)。

### 如果我们的IT团队忙于运维，我们这边应该由谁来主导实施？

需要两个角色：一位对流程做决定的业务负责人，以及一位在采购方一侧把控范围、期限和决策的人员。IT负责集成、基础设施和后续运维，但不应独自决定销售或会计应如何运作。我以管理层顾问的身份为这第二位人员提供支持：协助把控范围和进度，准备决策，并与供应商沟通——与您的IT团队并肩工作，而不是取而代之。

### 如何选择实施合作伙伴，并比较范围和价格各不相同的报价？

首先把各份报价统一到相同的范围：用一份需求矩阵，让每家供应商回答同样的问题。比较数年期的总成本（许可、实施、运维、变更），而不只是起步价格。要求基于您自身场景的演示，并核实实际参与项目的团队以及终止合作的条款。

### 没有业务分析师，我们该如何与供应商沟通？

不要问系统能做什么，而是拿出企业的真实案例，问系统将如何处理。记录达成的共识，并在后续会议中回顾。有一位站在您这边、既懂管理层语言又懂供应商语言的人会很有帮助——这正是我承担的角色：我准备问题、主持沟通，并把供应商的回答转化为对企业的实际影响。

### 实施延期或范围偏离实际需求时，该怎么办？

在问题扩大之前停下来做一次评审：合同里写了什么，哪些内容在未经决策的情况下发生了变化，哪些功能在上线时真正必需。变更和决策记录会有帮助，基于事实而非印象与供应商沟通同样有帮助。这样管理层就能获得对项目状态的独立评估，以及后续行动的备选方案。

### 如何从供应商处验收系统，运维合同中需要注意什么？

验收应基于事先约定的测试场景和标准，而不是笼统的印象。检查数据迁移、文档以及团队培训情况。在运维合同中，重点关注服务水平和响应时间、变更费用、对自身数据和文档的访问权限，以及终止合作的条款。

## 与ERP并行的流程平台， *而不是取代ERP。*

交易对手的数据只有在发生业务交易时才会进入ERP——而往来函件，包括与e-Doręczenia（波兰官方电子送达系统）的集成，还涉及一些可能永远不会出现在ERP中的主体。在仅靠ERP不够的地方，我们会设计一个独立的流程平台，与ERP及客户的核心系统集成，并针对具体的ERP和组织的特点量身定制。

### 采购链

采购申请、订单、合同、供应商关系管理、谈判、费用单据流转、供应商评估——一张流程图，取代分散的电子表格和邮件。

### 采购之外的流程

人事流程、从仓库发放样品，以及内部、外部、客户和供应商投诉——采用与采购流程相同的集成和数据归属规则。

## 总经理希望提升法务部门工作的可审计性。 *他没有时间与分析师开2小时的会。*

一家供热企业的法律支持模块。总经理希望法务部门像服务台（helpdesk）那样报告工作时间、受理请求，而不只是知道公司有多少法律事务、花费多少。他的意图是让有时分散在各分支机构的法务部门，在可审计性和可问责性上与外部律师事务所看齐——这些律所每月月底都会给他一份完整报告：谁处理了什么，在每个事项和请求上花了多少时间。管理层既没有时间与分析师开长时间的会议，也没有时间撰写需求——他们想看到一份成型的概念方案。

1. 1 **谈话 与管理层谈15–20分钟：想要监控什么、为什么，以及期望看到什么样的结果。**
2. 2 **概念方案 约2天内：服务台式的请求模型、事项登记册以及律师工时报告。**
3. 3 **决策 管理层评估的是一份成型的概念方案，而不是写在纸上的想法——“建还是不建”的决定基于具体的东西。**
4. 4 **实施** Krogis在实施团队中代表管理层——只有在需要做出实际决策时，管理层才再次介入。

**成果：** 如今，同一机构的法务部门已拥有采购程序电子档案和法律支持模块，它们是一个接一个、逐步累积的项目，基于同一机制：管理层提出意图，Krogis将其转化为行动。

## 从一次谈话， *到长期担任管理层代表。*

这一机制在与外国集团旗下一家工业子公司和一家金融子公司的多年合作中得到了验证：在集团与本地管理层之间充当“翻译”，直接与管理层、CFO和总会计师合作。

1. 01 **一次谈话得出概念方案或原型** 15–20分钟 + 约2天 与管理层就问题和目标进行谈话，无需研讨会，起步阶段也无需动用IT部门。一份成型的概念方案或原型，作为决策研究的输入——此时尚未产生任何实施成本。
2. 02 **面向实施的规格说明 时间在首次沟通后确定 方案获批后：需求、数据模型、集成和测试场景，转化为IT部门（内部团队或外部供应商）可以直接执行的内容——如有需要，还包括依据总部采购准则制作的比较矩阵，以及参与与供应商的谈判。**
3. 03 **实施团队中的管理层代表 项目期间 在由总部推动的大型项目中尤其有价值，例如迁移到集团统一的共享ERP：与供应商开会、讨论与本地系统的集成、确保实施忠实于最初的意图。管理层忙于财务、销售和营销等各自领域的日常职责，无需每天跟进项目，而是收到精炼的总结，用于自身决策以及与总部和IT部门的沟通。只有在需要管理层决策时，事项才会上报。**
4. 04 **数字化顾问 长期合作 基于同一机制的后续方案和项目，把集团总部的要求转化为本地行动，并随时了解同类企业在哪些技术决策上付出了过高代价。**

1. 2017–2026 **一家外国集团旗下的工业子公司** “在同一家企业持续发展同一个平台的第九年——作为变革管理负责人，而不是技术供应商，直接与管理层、CFO和总会计师合作。” 为一家跨国工业集团建立采购与发票流转。面向管理层、CFO和总会计师担任变革管理负责人。
2. 2016–2026 **一家国际控股集团——银行、租赁、保险** 实施业务流程管理（BPM）平台，设计并实施采购到付款（procure-to-pay）解决方案、差旅管理，以及与各业务系统（OCR、KSeF）的集成。使解决方案适应集团的采购程序。
3. 金融 **储蓄信贷合作社（SKOK）** 系统实施以及与各合作社的持续合作。

## 谁会读到这些。

- **总经理、管理层成员、所有者 需要就项目成果向监事会、所有者或集团总部负责——而且最没有时间梳理IT需求。在子公司中，要同时向本地管理层和集团总部负责。**
- **CFO、财务总监 需要在本地运营需求与集团采购准则和总部标准之间取得平衡——因此需要一个同时懂得两种语言的人。**
- **带领小团队的IT总监 是盟友，前提是管理层的方案传到他手上时，已经被转化为可以执行的内容——而不是又一个含糊的“想想办法”式要求。**

## 开始合作前最常被问到的问题。

### 管理层的想法多快能变成一份应用概念方案？

与管理层的谈话本身只需15–20分钟——足以讲清问题、目标和约束条件。约两个工作日内即可得到成型的概念方案或原型，此前不产生任何实施成本；它是用于决策的材料，而不是继续猜测的起点。

### 这能与总部采购准则相协调吗？

可以。总部采购准则从第一天起就纳入比较矩阵和需求之中，而不是到签约时才作为条件冒出来。管理层会收到一份总部看得懂的报价比较，如有需要可提供英文版。

### 这与聘请业务分析师或产品负责人有何不同？

分析师或产品负责人通常是组织结构中的固定岗位，需要您自己管理，并让其熟悉公司的情况。Krogis一开始就能在管理层层面开展工作，以项目方式合作（从单个方案到长期合作），并且对外代表管理层——面对供应商和实施团队，而不只是在单个项目内部。

### 如果我们已有IT部门，这项服务还有意义吗？

有，前提是IT部门规模较小，由IT技术人员而非负责与管理层对接的管理者组成。与管理层共同准备的方案传到IT部门时，已被转化为可以执行的内容，这会加快他们的工作，而不是与之竞争。如果已有一位经验丰富、进入管理层的CIO，这项服务就不适合。

### 在实施团队中代表管理层，实际是怎样的？

这意味着代表管理层参加日常工作会议，确保实施不偏离最初的意图，只在需要管理层决策时才上报。管理层随时了解进展，但不必出席每一次会议——既节省了时间，又不失去掌控。

## 告诉我管理层面临的问题。 *谈话两天后，您就会拿到概念方案。*

[写信至：wojciech.kroczak@krogis.pl](mailto:wojciech.kroczak@krogis.pl?subject=%E5%85%B3%E4%BA%8E%E6%96%B9%E6%A1%88%E7%9A%84%E6%B2%9F%E9%80%9A) [致电：+48 516 401 658](tel:+48516401658)

- 2个工作日内回复
- 首次沟通30分钟，免费
- 沟通可使用波兰语或英语