# Independent IT Advisor for Business: ERP Selection | Krogis

Źródło: https://krogis.pl/en/biznes
Język: en
Opis: You have a project, and your IT team is busy keeping the lights on. Requirements, vendor selection, oversight and handover of an ERP or other system — on the board’s side.

---

# A new system is half the project. *The other half is people.*

Krogis advises the boards of companies and subsidiaries of foreign groups that have a project to deliver while their own IT department is busy with operations. Selecting and implementing a new ERP, complaint handling, a process-driven CRM, a cost-invoice workflow ready for KSeF (Poland’s national e-invoicing system), contract management, employee onboarding and offboarding: I write up the requirements with the board, talk to your IT team and to vendors, compare offers (in subsidiaries, against head-office purchasing guidelines), advise on overseeing delivery and help prepare the change in how people work, so that after go-live they really use the new system. **One conversation, and you have a concept in about 2 days.**

[Book a call](mailto:wojciech.kroczak@krogis.pl?subject=A%20conversation%20about%20a%20concept) [See a completed example](https://krogis.pl/en/biznes#przyklad)

**Detail 1** parts on an engineer’s desk **scale 1: 1** illustrative photo **sheet 1** business

## Change management in a company. *Typical projects and what they change in people’s work.*

In a company, change is usually driven by results or by a head-office decision. People accept it faster once they understand what it means for them.

### Implementing an ERP or CRM

**What changes for people:** sales, finance and customer service work from shared data instead of their own spreadsheets.

**Typical difficulty:** pressure for quick results and the convenience of Excel: the new system loses to the spreadsheet if it isn’t more convenient from day one.

**What I focus on:** department heads as the first users, usage measures from the first week and a review after go-live.

### Process platform and workflow

**What changes for people:** requests, approvals and complaints follow one visible path instead of emails and phone calls.

**Typical difficulty:** every department has its own exceptions and wants the system to reflect all of them.

**What I focus on:** first describe the process and agree the exceptions with managers, then the system.

### A head-office decision rolled out in the subsidiary

**What changes for people:** the subsidiary takes on a tool or process chosen by head office.

**Typical difficulty:** “it wasn’t our idea”: head office’s goal doesn’t automatically become a reason for the local team.

**What I focus on:** translating head office’s goal into concrete benefits for people in the subsidiary, and a clear split of who is responsible for the change locally.

### AI agents and automation

**What changes for people:** some of the repetitive work is done automatically, while people check the results and handle exceptions.

**Typical difficulty:** worries about jobs, and automating an undocumented process, which only speeds up the mess.

**What I focus on:** first describe and tidy up the process and set out who is accountable, then automate, plus an honest conversation about how roles will change.

**KSC and NIS 2.** When a company provides services to entities covered by KSC, its clients will start requiring contract clauses and evidence from it. I help prepare the answers and documents without building a separate security department. [KSC from the board’s side](https://krogis.pl/en/uslugi/koordynacja#ksc)

[What change management is and why it pays off](https://krogis.pl/en/zarzadzanie-zmiana)

## Questions worth knowing the answer to.

I put them to board members and finance directors before a large rollout begins. If the answer to any of them is “we don’t know”, that is exactly where I can help.

1. **What exactly should change in people’s work once the new system goes live, and how will we measure it?**
2. **Who on our side translates the users’ needs into requirements for the vendor?**
3. **Are we comparing offers on a common scope and on total cost?**
4. **How will we make sure our IT team, busy keeping things running, is not overloaded by the project?**
5. **What will we do if the rollout starts to drift from the board’s intent?**

**The cost of a mistake.** An ERP rollout that does not meet people’s needs means the cost of licences, implementation and months of work with no effect. An advisor usually costs less than a single badly chosen technology, a single wrong vendor or a single trap in a contract.

## What you gain. *The documents are a tool, not the goal.*

- **The board’s time** 15–20 minutes of conversation instead of weeks of workshops. Decisions only where they are genuinely needed.
- **Fewer mistakes in ERP and other rollouts** The goal and the definition of success agreed before you choose a vendor.
- **A vendor held accountable for results** Requirements, acceptance criteria and a change log you can rely on.
- **People who actually use the system** Change management and change champions in each department, so the rollout doesn’t stay on paper.
- **Lower spend** A tool matched to the problem — and sometimes the decision that no new system is needed at all.

**Wojciech Kroczak** Change management and digitalisation advisor. 2017–2026: an industrial subsidiary of a foreign group. 2016–2026: an international holding — bank, leasing, insurance.

**For head office.** Krogis is an independent advisor to the local board of a Polish subsidiary. I turn a 15-minute conversation with the board into a concept within two days, write requirements the IT team and vendors can act on, compare offers against corporate purchasing guidelines and represent the board during implementation. No software sales, no vendor affiliations. A one-page summary in English is available on request.

## The board has a decision to make. *Nobody has time to write it up.*

The board knows exactly what problem it wants to solve and what risk it wants to close off — and putting that into words takes fifteen minutes, not a week of workshops.

Handed a general instruction, in-house IT starts by calling meetings and looking for off-the-shelf solutions — before anyone has written down what is really needed.

Without a concept or a prototype, it’s hard to tell whether an idea even makes business sense — the yes/no decision is made on gut feeling rather than on anything concrete.

Once the project is under way, the board either gets pulled into working meetings it has no time for or, conversely, loses sight of whether delivery still reflects its original intent.

**This is not for companies that already have an experienced, board-level CIO.** Krogis is a good fit where the board is closely involved in day-to-day operations and the IT department is small, staffed by IT specialists rather than managers, and taken up with maintenance — as in subsidiaries of large industrial and financial groups, in service and insurance companies, and in credit unions.

## We want to buy a hammer, *because… we need to hang a picture.*

Companies often struggle to say what they want, because they don’t know what they could ask for. The board says “we need to buy a system”, and after a series of probing questions — “what is this system for, what do you want to achieve with it, what do you imagine will happen after go-live?” — a definition of the real problem often emerges: “we want to handle complaints faster, report easily, cut costs, comply with headquarters’ guidelines, increase the profitability of sales in channel A.”

I ask about the goal and what will count as success, then work through the analysis methodically until we reach the real goal, which is often hidden behind the first idea for a system.

1. The request“We want to buy an invoice-workflow system.” The actual need - putting the whole purchasing policy in order, - describing and optimising the processes from requisition, through order and contract, to cost invoices, - vendor management rules.
2. The request“We need a CRM system.” The actual need - mapping the lifecycle of counterparty data: when and in which systems a counterparty is registered, who is responsible for it, and which business events should bring the customer’s data into other systems, - structured, digitised procedures for routing offers, - a process-based approach to registering, updating and verifying counterparty data, - tools that make preparing offers easier, - ways to automate marketing, - ways to automate sales activities, - sentiment monitoring of communication with prospective and existing customers. A container terminal. This was not a typical, simple CRM but a process-driven improvement to customer service.
3. The request“Do you have a marketing module for the CRM?” The actual need - a stakeholder relationship management tool, not another sales module.

I start with questions companies rarely ask themselves: what your ideal future looks like, what is causing you problems today, why we are doing this, what will count as done, and by what criteria we will judge the project a success. Rather than going straight to a vendor who “has a system for that”, we first agree on the goal. I can describe and analyse processes, but above all I steer the analysis and the questioning: within the organisation, in the definitions and in conversations with vendors. That way you don’t lose time, and you get faster to the outcome you are really after.

## Who does what when you roll out a system.

Complaints, cost-document workflow, service requests: the mechanism is the same whatever the module.

## Is this your situation? *Four things worth knowing before the first conversation.*

### What often points to it

It is common for your IT team to have its hands full with maintenance, while the project waits for someone to write the requirements. The vendor can end up proposing the scope and schedule itself. Head office or the board asks for a status, and the answer has to be pieced together from several sources. Project documentation is produced unevenly: it is not always clear who wrote it, who owns it and whether it has been approved.

### What may happen if you put it off

Scope can grow through changes raised along the way, cost and timing slip, and acceptance rests on the vendor’s assurances. New IT staff then join the project without organised knowledge of it.

### Who is usually the sponsor

Most often a board member (the CFO or the COO) who is accountable for the business outcome of the implementation.

### What I don’t do

I am not the vendor’s project manager. I am not responsible for the implementation or for whether your own staff deliver on time, but I help you monitor it: I do what the board often has no time for, which is making sure it is visible how the project is going, who is responsible for what and what needs a decision.

**The smallest safe first step:** a 30-minute call at no charge. From a 15–20 minute conversation with the board, I prepare a concept in about 2 days, without generating any implementation cost.

## Several projects at once, and head office wants a status. *Who pulls it together?*

An ERP rollout, a process-driven CRM, a KSeF document workflow, tidying up documentation: the IT department keeps the systems running, and the projects are often left without a standing coordinator. The board then has little time and an incomplete picture.

I act as a standing coordinator on the board’s side (in the language of large organisations, a PMO, or project management office). One picture of the projects, regular statuses and a report, in English too for head office.

- A list of projects with stages, deadlines, owners, dependencies and blockers, each with a green, yellow or red status.
- A weekly or fortnightly status meeting, a note, a list of actions and deadlines.
- Registers of risks, decisions and documentation: who the author is, who the owner is and what stage of approval it has reached.
- Coordinating information between the team, the people responsible for tasks and the vendors, and escalating when something stalls.
- The board remains the owner of decisions, budget and delivery. I don’t take on responsibility for the rollout; I make sure it is visible how it is going.

[Scope of project coordination and keeping projects in order](https://krogis.pl/en/uslugi#doradca)

## Rolling out an ERP or another major system. *Four points at which the board needs someone on its side.*

Your IT team keeps everything running day to day. An implementation project is a different job: the needs have to be described, a vendor selected, the talks conducted and the results accounted for. I can step in for one of these stages or see the whole course through with you.

1. **Preparation and requirements** A list of the processes, systems, data and integrations the new system is meant to take over or replace. A business owner with a mandate from the board, goals to verify after go-live, and requirements written in the language of your processes rather than a feature list from a vendor’s brochure.
2. **Choosing a vendor or implementation partner** A request for proposals, demos based on your own scenarios, offers normalised to a common scope and compared in a matrix: total cost over several years, the team, ways of working, maintenance terms and exit terms.
3. **Talks with** IT and oversight of delivery I represent the board in meetings with the vendor and with your IT team, and keep scope, schedule and change decisions under control. The board receives short summaries and only comes back in when its decision is needed.
4. **Acceptance and close-out** Acceptance against agreed test scenarios and criteria, verified data migration, documentation and training. A maintenance contract that makes you no more dependent on a single vendor than necessary.

How long this takes depends on the organisation and the project: how well prepared the company is, its organisational culture and the mandate the board gives the project. That is why we agree the timeline after the first conversation rather than in a price list.

### Questions I hear before a rollout

### How do we prepare the company for an ERP rollout?

Before you talk to vendors, write down what you have: the processes, systems, data, integrations and contracts the new system is meant to take over or work alongside. Appoint a business owner with a mandate from the board and agree how you will know the rollout has succeeded. Decide where you will adopt the system’s standard processes and where your own process is a competitive advantage worth keeping. Requirements written in the language of your processes let you compare offers and later hold the vendor accountable. A good starting point is an [inventory](https://krogis.pl/en/inwentaryzacja).

### Who on our side should lead the rollout if our IT team is busy with maintenance?

You need two roles: a business owner who decides on processes, and a person on the client side who keeps scope, deadlines and decisions on track. IT is responsible for integrations, infrastructure and subsequent maintenance, but should not decide on its own how sales or accounting ought to work. I support that second person as an advisor to the board: I help keep scope and schedule on track, prepare decisions and talk to vendors, alongside your IT team, not instead of it.

### How do we choose an implementation partner and compare offers that differ in scope and price?

First normalise the offers to a common scope: a single requirements matrix in which every vendor answers the same questions. Compare the total cost over several years (licences, implementation, maintenance, changes), not just the entry price. Ask for a demo based on your own scenarios, and check both the team that will actually work on the project and the terms for ending the contract.

### How do we talk to a vendor when we don’t have a business analyst?

Instead of asking what the system can do, present real cases from your company and ask how the system would handle them. Record what is agreed and refer back to it at later meetings. It helps to have someone on your side who speaks both the board’s language and the vendor’s — that is the role I play: I prepare the questions, conduct the conversations and translate the answers into their consequences for the company.

### What do we do when the rollout is running late or the scope drifts from actual needs?

Pause for a review before the problem grows: what is in the contract, what has changed without a decision, and which features are genuinely needed at launch. A log of changes and decisions helps, as does a conversation with the vendor based on facts rather than impressions. The board then gets an independent assessment of the project’s state and options for what to do next.

### How do we accept a system from a vendor, and what should we watch for in a maintenance contract?

Acceptance should be based on test scenarios and criteria agreed in advance, not a general impression. Check the data migration, the documentation and the training of your team. In the maintenance contract, look closely at service levels and response times, the cost of changes, access to your own data and documentation, and the terms for ending the contract.

## A process platform alongside ERP, *not instead of it.*

Counterparty data only reaches the ERP when a business transaction occurs — yet correspondence, including integration with e-Doręczenia (the national e-delivery service), also involves parties that may never appear in the ERP at all. Where the ERP alone is not enough, we design a separate process platform integrated with the ERP and the client’s central systems, tailored to that particular ERP and to the organisation’s specific needs.

### The purchasing chain

Requisition, order, contract, vendor relationship management, negotiation, cost-invoice workflow, vendor evaluation — one process map instead of scattered spreadsheets and e-mails.

### Processes alongside purchasing

HR processes, issuing samples from the warehouse, internal, external, customer and vendor complaints — the same rules on integration and data ownership as in purchasing.

## The CEO wanted to improve the auditability of the legal department’s work. *He had no time for a 2-hour meeting with an analyst.*

A legal-support module at a district heating company. The CEO wanted the legal department to report its working time and take in requests the way a helpdesk does, rather than merely knowing how many legal matters the company had and what they cost. His intention was for the legal department, at times spread across several branches, to be as auditable and accountable as the external law firms that send him a full report at the end of every month: who worked on what, and how much time went into each matter and request. The board had no time for hours of meetings with an analyst or for writing requirements — it wanted to see a finished concept.

1. 1 **Conversation** 15–20 minutes with the board: what it wants to monitor, why, and what visible result it expects.
2. 2 **Concept** Within about 2 days: a helpdesk-style request model, a register of matters and time reporting for the lawyers.
3. 3 **Decision** The board assesses a finished concept, not an idea sketched on paper — the decision to build or not is taken on something concrete.
4. 4 **Rollout** Krogis represents the board on the implementation team — the board is only brought back in for real decisions.

**Result:** the legal department at the same organisation now has a digital archive of procurement proceedings and a legal-support module, delivered as successive projects, each building on the last, using the same mechanism: the board sets out its intent, Krogis turns it into action.

## From a single conversation *to a standing role as the board’s representative.*

The same mechanism has proved itself over many years of work with an industrial and a financial subsidiary of foreign groups: acting as translator between the corporation and the local board, working directly with the board, the CFO and the chief accountant.

1. 01 **A concept or prototype from one conversation** 15–20 min + ~2 days A conversation with the board about the problem and the goal, without workshops and without pulling in the IT department at the outset. A finished concept or prototype as input to the decision study — before any implementation costs.
2. 02 **Specification for delivery** Timeline set after the first conversation Once the concept is approved: requirements, data model, integrations and test scenarios, translated into terms your IT department (in-house or an external vendor) can act on — plus, if needed, a comparison matrix based on head-office purchasing guidelines and participation in vendor talks.
3. 03 **The board’s representative on the implementation team** For the duration of the project Particularly valuable on a large project imposed by head office, such as migration to a shared, central ERP: meetings with vendors, discussions on integration with local systems, and making sure delivery stays true to the original intent. The board, stretched by day-to-day responsibilities in its own areas of finance, sales and marketing, receives condensed summaries to support its own decisions and its communication with head office and the IT department, instead of following the project day to day. Matters are escalated to the board only when its decision is needed.
4. 04 **Digitalisation advisor** Ongoing advisory role Further concepts and projects built on the same mechanism, translating group head-office requirements into local action, and an up-to-date view of where similar companies have overpaid for technology decisions.

1. 2017–2026 **An industrial subsidiary of a foreign group** “The ninth year of developing the same platform within the company — working directly with the board, the CFO and the chief accountant as change-management lead, not as a technology vendor.” Purchasing and invoice workflow for an international industrial corporation. Leading change management with the board, the CFO and the chief accountant.
2. 2016–2026 **An international holding — bank, leasing, insurance** Implementation of a business process management platform, concept design and implementation of a procure-to-pay solution, business travel handling, and integration with line-of-business systems (OCR, KSeF). Adapting the solution to corporate purchasing procedures.
3. Finance **Credit unions (SKOK)** System implementations and ongoing work with the credit unions.

## Who reads this.

- **CEO, board member, owner** Accountable for the project’s outcome to the supervisory board, the owner or head office — and has the least time to formulate IT requirements. In a subsidiary, answers to the local board and to head office at the same time.
- **CFO,** Finance Director Has to reconcile local operational needs with corporate purchasing guidelines and head-office standards — and needs someone fluent in both languages.
- **IT** Director with a small team An ally, provided the board’s concept reaches them already translated into something they can act on — not yet another vague “do something about this” request.

## What people ask most often before we start.

### How quickly can a board’s idea be turned into an application concept?

The conversation with the board itself takes 15–20 minutes — enough to describe the problem, the goal and the constraints. A finished concept or prototype follows within about two working days, before any implementation costs are incurred, as material for a decision rather than for further speculation.

### Can this be reconciled with head-office purchasing guidelines?

Yes. Head-office purchasing guidelines are built into the comparison matrix and the requirements from day one, rather than surfacing as a condition at signing. The board receives a comparison of offers in a format head office understands, in English if needed.

### How is this different from hiring a business analyst or a product owner?

An analyst or product owner is usually a permanent position in the structure, which you have to manage yourself and bring up to speed on the company’s context. Krogis comes in already able to work at board level, works on a project basis (from a single concept to ongoing cooperation) and represents the board externally as well — with vendors and the implementation team, not just within a single project.

### Does this service make sense if we already have an IT department?

Yes, as long as the IT department is small and staffed by IT specialists rather than managers who handle the relationship with the board. A concept prepared with the board reaches IT already translated into something they can act on, which speeds up their work instead of competing with it. It is not a fit where an experienced, board-level CIO is already in place.

### What does representing the board on the implementation team look like in practice?

It means attending day-to-day working meetings on the board’s behalf, making sure delivery does not drift from the original intent, and escalating to the board only when its decision is needed. The board is kept informed of progress but does not have to attend every meeting — it gets its time back without losing control.

## Tell me about the board’s problem. *You’ll have a concept two days after our conversation.*

[Write to: wojciech.kroczak@krogis.pl](mailto:wojciech.kroczak@krogis.pl?subject=A%20conversation%20about%20a%20concept) [Call: +48 516 401 658](tel:+48516401658)

- I reply within 2 working days
- First call: 30 minutes, no charge
- The call can be in Polish or English