KSeF与发票流转
对人来说有什么变化:发票以电子方式到达,填写说明和审批都在系统里完成,而不是靠纸张在部门之间传递。
常见难点:一部分负责审批发票的人很少坐在办公桌前,所以新的流程必须适应他们的工作日。
我关注的重点:适合一线工作的审批路径、代理审批安排、让部门负责人最先接手,以及上线后检查发票卡在哪里。
Krogis为市政公用企业(供热、供水、城市公共交通和港口)应对IT项目带来的变化提供咨询:符合KSeF的发票流转、与财务会计系统的集成、电子人事档案、电子签名、ERP更换。我帮助企业把这些项目排成一个统一的先后顺序,让各级负责人以及办公室和一线的员工做好准备,在提交监事会之前对报价进行独立评估(哪些能与财务会计系统集成,五年内的真实成本是多少,如何按同一套标准比较两份报价),并在实施后检查大家是否真的换了一种方式工作。面向供热企业、供水企业、城市公共交通企业和港口企业。
在市政公用企业,变化同时涉及办公室和一线人员,而责任则分散在管理层、监事会和所有者之间。
对人来说有什么变化:发票以电子方式到达,填写说明和审批都在系统里完成,而不是靠纸张在部门之间传递。
常见难点:一部分负责审批发票的人很少坐在办公桌前,所以新的流程必须适应他们的工作日。
我关注的重点:适合一线工作的审批路径、代理审批安排、让部门负责人最先接手,以及上线后检查发票卡在哪里。
对人来说有什么变化:文件和员工档案都放在系统里,签字和归档不再需要文件夹。
常见难点:对纸质文件的习惯,以及担心“放进系统就找不到了”。
我关注的重点:哪些只是扫描,哪些在流程中真正改变;从哪些部门开始;实施后由谁在企业里维持秩序。
对人来说有什么变化:几乎所有人的工作都会改变:会计、仓库、结算和客户服务。
常见难点:旧系统和自己的表格用着顺手,如果没人事先规划,新系统就会输给它们。
我关注的重点:让部门负责人先做好准备,用企业自己的数据做培训,并在3–6个月后复盘:大家是否真的在新系统里工作。
对人来说有什么变化:有法定期限的函件和程序全部转为电子方式办理。
常见难点:涉及法定期限时,人们更愿意用熟悉的老办法,也害怕出错。
我关注的重点:清晰的流程、代理安排,以及给不常做这件事的人准备的一份简明操作提示。
KSC与NIS 2。供热公司、供水公司和公共交通企业是典型的KSC覆盖对象。义务落在公司管理层身上;我帮助把义务拆解成具体任务,盯紧供应商,并让公司为审计做好准备。 从管理层角度看KSC
这些问题,我会在公用事业公司的总裁和董事会成员签署合同之前向他们提出。如果其中有哪一个的回答是“我们不知道”,那正是我可以帮上忙的地方。
出错的代价。 较低的起步价,往往小于补充协议、签约后追加的集成以及此后多年运维的成本。顾问的费用通常低于一项选错的技术、一家不合适的供应商,或合同中的一个陷阱。
市政公用企业或港口企业通常拥有自己的IT部门和投资预算——但数字化方向的决策往往只基于一份建议,缺少对风险、成本和替代方案的外部核查。
您不是行政机关。商业公司的逻辑不同于政府机关:决策周期不同,论证决策的方式不同,业绩压力也不同。我们用您的语言合作——风险、成本、运营连续性——而不是行政语言。
强制性结构化电子发票(KSeF,波兰国家电子发票系统)要求与现有财务会计系统集成,而不只是购买一个新模块。
盘点成果:财务会计系统集成矩阵,以及必须与其交换数据的系统清单。
新系统与现有财务会计系统的集成是最常见的矛盾焦点——问题是“能不能接上”,而不是“要不要全部更换”。
盘点成果:从第一天起就写入需求规格的集成要求,而不是签约后用补充协议补上。
每个新增模块要么接入您现有的系统,要么成为又一个应用孤岛,让公司为此付两次钱。
盘点成果:A/B/C/D分类及实施顺序。
许多市政公用企业,尤其是供热、供水和交通领域的企业,即便以商业公司的形式运营,也属于修订后的KSC法(波兰国家网络安全体系法)的适用范围。
盘点成果:系统登记册和风险登记册。
大型一体化ERP听起来稳妥,但可能变成对单一供应商的全面依赖——既缺乏灵活性,也没有容纳新技术的空间。没有唯一正确的答案:这取决于公司的商业模式和规模。
盘点成果:哪些留在ERP中,哪些更适合拆分为独立且集成良好的系统。
IT负责人能识别需求,却无权要求其他部门负责人配合——缺的是推动力,而不是知识。
盘点成果:管理层授权外部顾问,收集IT部门所需的信息。
没有统一的比较矩阵,比较的就是不可比的东西,胜出的是更好的演示,而不是更好的报价。
盘点成果:在与供应商会面之前就确定比较标准,而不是在会面过程中。
在公司购买又一个模块之前,我会先问:为什么要买,什么才算成功?常常会发现,对某个系统的需求背后,是一个需要先理顺的流程,工具只是第二步。
需求“我们需要一个适配KSeF的发票流转系统。”
有时监事会询问成本和风险,而管理层手里只有本公司IT提出的一份建议。与财务会计系统的集成往往要到合同签署之后才暴露出来。KSeF、e-Doręczenia和文档流转项目常由不同的供应商负责。
补充协议和运维成本常常不断上升,因为起步价格并不能反映五年的总成本。当需求是由供应商来描述时,ERP或发票流转的更换可能会推迟。此时管理层在没有第二方独立意见的情况下作出决定。
通常是总裁,或分管财务的管理层成员,与IT负责人共同推进。
我不替代IT部门,不介入其职责范围,也不销售系统。决策仍由管理层和监事会作出。
最小而稳妥的第一步:一次30分钟的免费交流,之后是盘点(2–6周,费用可在首次交流后告知,低于公共采购门槛)。在此之前,您无需作出任何承诺。
KSeF、与财务会计系统的集成、ERP更换以及后续各个模块,分别由不同的人员和不同的供应商负责。IT部门有时规模不大,维护完系统之后,留给项目协调的只是所剩无几的精力。
我把目前分散的内容集中到一处:项目、期限、相互依赖、决策以及供应商的承诺。立足公司一侧,不触及IT部门的职权。
一页给总经理和总会计师的摘要,一份用于管理层会议的演示文稿,以及一整套用于与供应商沟通的文件。
| 您的计划 | 管理层获得什么 | 化解哪些风险 |
|---|---|---|
| 适配KSeF的发票流转 | 财务会计系统集成矩阵、需求规格要求、集成方案与新系统方案及其5年成本。 | 在财务会计系统旁又多一个应用孤岛、为集成支付补充协议费用、数据重复录入。 |
| 与财务会计系统及ERP的集成 | 从第一天起写入需求规格的集成要求、向供应商提出的问题。 | 签约后才发现“接不上”,只好更换一个谁都不想换的系统。 |
| 电子人事档案及后续模块 | A/B/C/D分类、实施顺序、变革管理计划。 | 团队一开始就抵触,模块之间互不相通。 |
| 监事会与所有者 | 一页式建议、基于统一标准的报价比较、5年总成本。 | 决策“凭演示”做出,事后被追问依据。 |
取决于系统和部门的数量。在就公司规模进行30分钟沟通后,我会确认具体价格。
依据本公司IT部门的建议对IT项目作出决策——需要在签字之前,而不是事后,获得第二份独立意见。
获得:一页式建议和两个附5年成本的决策方案,可直接提交监事会。
收获:一个能在监事会面前站得住脚的决策。
负责新系统与现有财务会计系统的集成——这通常是每个项目中第一个、也是最难解决的争议点。
获得:财务会计系统集成矩阵,以及可以写进供应商合同并据此要求履行的要求。
收获:可预期的成本,以及无需补充协议的集成。
当独立评估用数据和管理层视角的论据支撑其建议时,外部顾问是盟友,而不是取代其角色的竞争者。
获得:系统登记册、可重复使用的方法论,以及支持自身建议的管理层论据。
收获:对自身建议的独立确认。
同样的合作方式已在一家集装箱码头的数字化中得到验证:管理层会议桌旁多了一个外部的独立声音,与公司自有IT部门的专业能力并行,而非替代。
系统、集成和依赖关系登记册,重点关注财务会计系统及其关联。A/B/C/D分类和风险地图。一页式管理层摘要。
在管理层批准IT部门的建议之前:就风险、总成本和替代方案提供第二份意见。指出处境相似的其他企业在哪些地方多花了钱,因为它们没有预见到集成、数据迁移或团队的抵触。当总经理有想法却没时间把它写成文字时,15–20分钟的沟通就足够,我会在约2天内带着一份成型的概念方案回来供您评估。
按统一标准比较两份(或更多)报价的矩阵、向供应商提出的问题,以及作为管理层代表参加会谈——让提交给总经理的决策建立在可比数据之上,而不是取决于演示的说服力。
参加与供应商的会议,与贵公司IT部门的建议并行、对后续项目提出意见,并持续了解类似企业在云、API或自动化决策上在哪些地方多花了钱。
如今,这家机构的法务部门已拥有采购程序电子档案、结合OCR的发票流转、KSeF集成和法律支持模块。这些是逐步递进、层层叠加的项目,建立在同一机制之上:管理层提出意图,Krogis将其转化为行动。
“与集装箱码头数字化相同的工作方式——在公司自有IT部门的专业能力之外,为管理层提供一个独立的声音,而不是取而代之。”
基于流程平台、面向客户服务部和销售部的CRM系统:联系人管理、网站询价、报价核算与编制、投诉处理,至今仍在使用。明确目标、分析需求,并制定利益相关方关系管理系统的概念方案。拥有大型基础设施运营方数字化的经验。
设计、实施并上线协同办公与业务流程管理平台,涵盖采购程序电子档案、费用单据电子流转、电子人事档案、往来函件管理和法律支持等。
数字化沟通中反复出现、经过匿名处理的话题——并非引自某一家具体企业。
“在继续推进之前,我必须知道这到底能不能和我们的财务会计系统对接——其他都是次要的。”
“我们总是把两份报价并排摆在管理层面前——我们需要有人帮我们公平地比较,而不只是挑出演示做得更漂亮的那一份。”
“即使流程已经自动化,我也希望在我认为有必要时,真正能够手动作出决定。”
“我们不希望被当成公共机构——我们是企业,对风险和业绩的考量与政府机关不同。”
在大多数情况下,可以通过API或专门的集成来实现,前提是从第一天起就把集成要求写入需求规格,而不是在合同签订后通过补充协议补上。这是市政公用企业IT项目中最常见的争议点之一——也是最容易提前解决的问题之一。
是的。根据自2026年4月3日起施行的修正案,承担公用事业性质任务的公司无论规模大小,至少作为重要实体受该法约束。供热、供水或交通业务还可能使其在所属行业被认定为关键实体——这一点值得逐案核实。商业公司的组织形式并不能免除相关义务。
需要一套统一的标准矩阵——功能、架构与开放性、安全与合规、技术与供应商、总成本——并在与供应商会面之前确定,而不是在会面过程中。没有它,往往会比较不可比的东西,胜出的是更好的演示,而不是更好的报价。
是的。《波兰商业公司法》的逻辑不同于行政管理的逻辑:决策周期不同,财务业绩的压力不同,而且某些义务(例如公共采购)对公司的适用程度可能与政府机关不同。因此,面向市政公用企业的沟通和咨询应使用商业语言——风险、成本、连续性——而不是行政语言。
需要计算数年期内的总拥有成本——许可、实施、运维、培训、集成——并与现有分散系统的实际成本相比较,而不是与它们多年前的标价相比。“一个平台就能省钱”这类笼统说法,一旦把账算清,通常就站不住脚。
首先列出新系统需要协同的对象:财务会计系统、适配KSeF的发票流转、技术系统和客户服务。确定公司内由谁对流程作出决策,并在开始与供应商洽谈之前写明需求,包括集成需求。在同一个矩阵中、按总成本比较报价,并以商定的测试场景作为验收依据。