Selecting and implementing a new ERP, complaint handling, a process-driven CRM, a KSeF-ready cost-invoice workflow, 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), and oversee delivery of the project and the organisational change that comes with it. One conversation, and you have a concept in about 2 days.
- 15–20 min
- with the board — enough for it to describe the problem and the goal
- ~2 days
- to a finished concept or prototype, before any implementation costs are incurred
- 0 meetings
- added to the board’s diary until there is a real decision to take
What you get. The documents are a tool, not the goal.
- The board’s time15–20 minutes of conversation instead of weeks of workshops. Decisions only where they are genuinely needed.
- Fewer mistakes in ERP and other rolloutsThe goal and the definition of success agreed before you choose a vendor.
- A vendor held accountable for resultsRequirements, acceptance criteria and a change log you can rely on.
- People who actually use the systemChange management and change champions in each department, so the rollout doesn’t stay on paper.
- Lower spendA tool matched to the problem — and sometimes the decision that no new system is needed at all.
Dla centrali. Krogis to niezależny doradca lokalnego zarządu polskiej spółki-córki. Z 15-minutowej rozmowy z zarządem w ciągu dwóch dni przygotowuję koncepcję, piszę wymagania, na podstawie których dział IT i dostawcy mogą działać, porównuję oferty z korporacyjnymi zasadami zakupów i reprezentuję zarząd w czasie wdrożenia. Bez sprzedaży oprogramowania, bez powiązań z dostawcami. Jednostronicowe podsumowanie po angielsku jest dostępne na życzenie.
For headquarters. 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.
Für die Konzernzentrale. Krogis ist unabhängiger Berater des lokalen Vorstands einer polnischen Tochtergesellschaft. Aus einem 15-minütigen Gespräch mit dem Vorstand entsteht innerhalb von zwei Tagen ein Konzept. Ich schreibe Anforderungen, mit denen IT-Team und Anbieter arbeiten können, vergleiche Angebote mit den Einkaufsrichtlinien des Konzerns und vertrete den Vorstand während der Umsetzung. Kein Softwareverkauf, keine Bindung an Anbieter. Eine einseitige Zusammenfassung auf Englisch ist auf Anfrage erhältlich.
Pour le siège. Krogis est un conseiller indépendant auprès de la direction locale d’une filiale polonaise. D’un entretien de 15 minutes avec la direction, je tire un concept en deux jours, je rédige des exigences exploitables par l’équipe informatique et les fournisseurs, je compare les offres aux règles d’achat du groupe et je représente la direction pendant la mise en œuvre. Aucune vente de logiciels, aucun lien avec des fournisseurs. Une synthèse d’une page en anglais est disponible sur demande.
Para la sede central. Krogis es un asesor independiente de la dirección local de una filial polaca. A partir de una conversación de 15 minutos con la dirección, preparo un concepto en dos días, redacto requisitos con los que el equipo de TI y los proveedores pueden trabajar, comparo las ofertas con las directrices de compras del grupo y represento a la dirección durante la implantación. Sin venta de software ni vínculos con proveedores. Bajo petición, un resumen de una página en inglés.
Til hovedkontoret. Krogis er uafhængig rådgiver for den lokale direktion i et polsk datterselskab. En 15-minutters samtale med direktionen bliver til et koncept inden for to dage. Jeg skriver krav, som IT-afdelingen og leverandørerne kan arbejde ud fra, sammenligner tilbud med koncernens indkøbsretningslinjer og repræsenterer direktionen under implementeringen. Intet softwaresalg, ingen leverandørbindinger. Et resumé på én side på engelsk kan fås på anmodning.
For hovedkontoret. Krogis er uavhengig rådgiver for den lokale ledelsen i et polsk datterselskap. En 15-minutters samtale med ledelsen blir til et konsept i løpet av to dager. Jeg skriver krav som IT-avdelingen og leverandørene kan jobbe ut fra, sammenligner tilbud med konsernets innkjøpsretningslinjer og representerer ledelsen under implementeringen. Ingen programvaresalg, ingen leverandørbindinger. Et sammendrag på én side på engelsk fås på forespørsel.
För huvudkontoret. Krogis är oberoende rådgivare till den lokala ledningen i ett polskt dotterbolag. Ett 15 minuter långt samtal med ledningen blir ett koncept inom två dagar. Jag skriver krav som IT-avdelningen och leverantörerna kan arbeta utifrån, jämför anbud med koncernens inköpsriktlinjer och företräder ledningen under införandet. Ingen programvaruförsäljning, inga leverantörsband. En sammanfattning på en sida på engelska finns på begäran.
Konsernin pääkonttorille. Krogis on puolalaisen tytäryhtiön paikallisen johdon riippumaton neuvonantaja. 15 minuutin keskustelusta johdon kanssa syntyy konsepti kahdessa päivässä. Kirjoitan vaatimukset, joiden pohjalta IT-tiimi ja toimittajat voivat toimia, vertaan tarjouksia konsernin hankintaohjeisiin ja edustan johtoa käyttöönoton aikana. Ei ohjelmistomyyntiä, ei sidoksia toimittajiin. Yhden sivun englanninkielinen yhteenveto on saatavilla pyynnöstä.
للمقر الرئيسي. Krogis مستشار مستقل لمجلس الإدارة المحلي لشركة تابعة في بولندا. أحوّل محادثة مدتها 15 دقيقة مع مجلس الإدارة إلى تصوّر خلال يومين، وأكتب متطلبات يمكن لفريق تقنية المعلومات والموردين العمل بها، وأقارن العروض بإرشادات الشراء المعتمدة في المجموعة، وأمثّل مجلس الإدارة أثناء التنفيذ. لا أبيع برمجيات ولا تربطني علاقات بالموردين. يتوفر عند الطلب ملخص من صفحة واحدة باللغة الإنجليزية.
致集团总部：Krogis 是波兰子公司本地管理层的独立顾问。我能在两天内把与管理层 15 分钟的谈话变成一份方案，撰写 IT 团队和供应商可以直接据以执行的需求，对照集团采购准则比较各方报价，并在实施期间代表管理层。不销售软件，不隶属于任何供应商。如有需要，可提供一页英文摘要。
본사 담당자께. Krogis는 폴란드 자회사 현지 경영진의 독립 자문가입니다. 경영진과의 15분 대화를 바탕으로 이틀 안에 콘셉트를 만들고, IT 팀과 공급업체가 바로 실행할 수 있는 요구사항을 작성하며, 그룹 구매 지침에 따라 제안서를 비교하고, 구현 기간 동안 경영진을 대변합니다. 소프트웨어를 판매하지 않으며 특정 공급업체와 관계가 없습니다. 요청 시 영문 1페이지 요약본을 제공합니다.
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.
Want to buy a hammer? I’ll ask why first.
Companies often struggle to say what they want, because they don’t know what they could ask for. The board says it needs a hammer; ask “what for?” and it turns out it wants to hang a picture — which may not need a hammer at all. 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.
-
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.
-
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.
-
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.
Board
Describes the problem and the goal in 15–20 minutes. Takes decisions only at the points that genuinely require them: the concept, vendor selection, acceptance.
Krogis
A concept or prototype, requirements and test scenarios, questions for vendors, a comparison matrix based on head-office purchasing guidelines, and representing the board on the implementation team and at acceptance. The prototype has to be shown to the board as early as possible, to confirm the goals and needs it must meet and the pain points it must eliminate. Only when we are sure of the right direction and the project’s definition of success do we begin the substantive work with departments and start meeting vendors.
IT department and vendor
Build the solution, integrate it with the ERP and maintain it, working to requirements that can be enforced. Your in-house IT team receives a task already translated into something it can act on.
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.
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.
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.
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.
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.
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 client-side project lead 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 can fill that second role on the board’s behalf, 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, 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
Conversation
15–20 minutes with the board: what it wants to monitor, why, and what visible result it expects.
- 2
Concept
Within about 2 days: a helpdesk-style request model, a register of matters and time reporting for the lawyers.
- 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
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.
- 01
A concept or prototype from one conversation
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.
- 02
Specification for delivery
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.
- 03
The board’s representative on the implementation team
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.
- 04
Your digital strategy advisor
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.
- 2017–2026An 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.
- 2016–2026An 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.
- FinanceCredit 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.
- I reply within 2 working days
- First call: 30 minutes, no charge
- The call can be in Polish or English